>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3582700. --> Reported by: [aangel](https://www.drupal.org/user/69305) Related to !1444 >>> <p><strong>Problem/Motivation</strong></p> <p>Drupal AI already provides a strong provider framework and a growing ecosystem of API-backed provider modules. However, one workflow is still missing: using local AI CLI tools from a Drupal site, especially when Drupal runs inside DDEV or another containerized environment.</p> <p>This affects tools such as:</p> <ul> <li>Claude CLI</li> <li>Codex CLI</li> <li>OpenCode</li> <li>Ollama</li> </ul> <p>Today, these tools are often installed and authenticated on the host OS, not inside the DDEV container. That makes them awkward or impossible to use from Drupal unless there is a bridge between the container and the host.</p> <p>I have already prototyped this pattern in another project and confirmed that it works in practice:</p> <ul> <li>direct CLI execution when the binary is available locally</li> <li>host-bridge execution when Drupal runs in DDEV and the CLI is installed on the host</li> </ul> <p>I do not think this should introduce a parallel backend framework. Instead, it seems like a better fit as one Drupal AI ecosystem project with a shared base module plus provider submodules that plug into the existing provider architecture.</p> <p><strong>Proposed resolution</strong></p> <p>Create a new Drupal AI ecosystem project for CLI-backed providers.</p> <p>Initial scope:</p> <ul> <li>chat support only</li> <li>provider modules for: <ul> <li>Claude CLI</li> <li>Codex CLI</li> <li>OpenCode</li> <li>Ollama</li> </ul> </li> <li>support two execution modes: <ul> <li><code>direct</code></li> <li><code>host_bridge</code></li> </ul> </li> </ul> <p>Suggested shape:</p> <ul> <li>a shared base module for bridge/execution plumbing</li> <li>provider modules per CLI backend</li> </ul> <p>For example:</p> <ul> <li><code>ai_provider_host_cli</code></li> <li><code>ai_provider_claude_cli</code></li> <li><code>ai_provider_codex_cli</code></li> <li><code>ai_provider_opencode_cli</code></li> <li><code>ai_provider_ollama_cli</code></li> </ul> <p>This would:</p> <ul> <li>reuse Drupal AI&rsquo;s existing provider/model/config framework</li> <li>avoid duplicating <code>AiProviderPluginManager</code> and related abstractions</li> <li>add a missing execution path for local/host-native CLI tools</li> <li>make DDEV-based Drupal sites able to use host-installed CLI tools through an explicit bridge</li> </ul> <p><strong>Why this is useful</strong></p> <ul> <li>local AI usage without routing everything through remote API providers</li> <li>access to host-installed AI tools from DDEV</li> <li>a Drupal AI-compatible way to use CLI tools that are already part of the workflow</li> <li>lets projects like Drush-based tooling consume Drupal AI providers instead of maintaining their own parallel backend abstractions</li> </ul> <p><strong>Remaining tasks</strong></p> <ul> <li>define the shared base module and provider submodule structure</li> <li>define the minimal provider capability surface</li> <li>agree on execution-mode configuration</li> <li>build a Claude-first MVP</li> <li>extend the same pattern to Codex, OpenCode, and Ollama</li> </ul> <p><strong>Possible MVP</strong></p> <p>Phase 1:</p> <ul> <li><code>ai_provider_host_cli</code></li> <li><code>ai_provider_claude_cli</code></li> <li>chat only</li> <li>both <code>direct</code> and <code>host_bridge</code></li> </ul> <p>Phase 2:</p> <ul> <li><code>ai_provider_codex_cli</code></li> <li><code>ai_provider_opencode_cli</code></li> <li><code>ai_provider_ollama_cli</code></li> </ul> <p><strong>Background</strong></p> <ul> <li>CLI-backed execution</li> <li>DDEV host-bridge execution</li> <li>Drush setup/bridge helpers</li> <li>real-world testing against host-installed CLIs</li> </ul> <h3 id="summary-ai-usage">AI usage (if applicable)</h3> <p>[X] AI Assisted Issue<br> This issue was generated with AI assistance, but was reviewed and refined by the creator.</p> <p>[ ] AI Assisted Code<br> This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision.</p> <p>[X] AI Generated Code<br> This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human.</p> <p>[ ] Vibe Coded<br> This code was generated by an AI and has only been functionally tested.</p>