feat: multi-provider support via OpenClaude (env var injection)

[NeritonDias]

EvoNexus now supports multiple AI providers beyond Anthropic. When the user selects a non-Anthropic provider (OpenRouter, OpenAI, Gemini, Codex Auth, AWS Bedrock, Vertex AI), the system uses the openclaude binary (npm install -g @gitlawb/openclaude) and injects provider-specific environment variables (CLAUDE_CODE_USE_OPENAI, OPENAI_BASE_URL, etc.) into the spawned CLI process. Anthropic continues using the native claude binary with no extra config.

How it works

Provider config is stored in config/providers.json with:

• active_provider: which provider is active ("anthropic", "openrouter", etc.)
• providers.<id>.cli_command: which binary to spawn ("claude" or "openclaude")
• providers.<id>.env_vars: env vars to inject into the CLI process

When a terminal session or ADW routine starts, the system:

1. Reads config/providers.json
2. Resolves the CLI binary (claude or openclaude)
3. Merges provider env vars into the process environment
4. Spawns the CLI with the correct binary + env vars

Changes

New files

• config/providers.json — Provider registry with 7 providers (Anthropic, OpenRouter, OpenAI, Gemini, Codex Auth, Bedrock, Vertex)
• dashboard/backend/routes/providers.py — REST API for provider management: list, get/set active, get/update config, test connection. API keys are masked in responses for security.
• dashboard/frontend/src/pages/Providers.tsx — Dashboard page with provider cards, configuration modal (env var forms), test connection button, and activate/deactivate flow. Uses Evolution dark theme.

Modified files

• dashboard/terminal-server/src/claude-bridge.js — Added _loadProviderConfig() to read active provider from config/providers.json. findClaudeCommand() now resolves either claude or openclaude based on provider config. startSession() merges provider env vars into the PTY spawn environment.
• ADWs/runner.py — Added _get_provider_config() to read CLI command and env vars from config/providers.json. run_claude() now uses the active provider's binary and injects env vars into subprocess.Popen().
• setup.py — Added choose_provider() step to the setup wizard. Lets user pick from 7 providers, checks if openclaude is installed, prompts for provider-specific env vars (API key, base URL, model), and saves to config/providers.json.
• dashboard/backend/app.py — Registered providers blueprint.
• dashboard/frontend/src/App.tsx — Added /providers route.
• dashboard/frontend/src/components/Sidebar.tsx — Added Providers nav item under System section.
• .env.example — Added AI Provider Configuration section with examples for OpenRouter, OpenAI, and Gemini.

Supported providers

Provider	Binary	Key env vars
Anthropic	claude	(native auth)
OpenRouter	openclaude	CLAUDE_CODE_USE_OPENAI, OPENAI_BASE_URL, KEY, MODEL
OpenAI	openclaude	CLAUDE_CODE_USE_OPENAI, OPENAI_API_KEY, MODEL
Gemini	openclaude	CLAUDE_CODE_USE_GEMINI, GEMINI_API_KEY, MODEL
Codex Auth	openclaude	CLAUDE_CODE_USE_OPENAI, OPENAI_API_KEY
AWS Bedrock	openclaude	CLAUDE_CODE_USE_BEDROCK, AWS_REGION, TOKEN
Vertex AI	openclaude	CLAUDE_CODE_USE_VERTEX, PROJECT_ID, REGION

Summary by Sourcery

Add multi-provider AI support configurable via providers.json, wiring the chosen provider’s CLI binary and environment variables into both the ADW runner and terminal server, and exposing provider selection and status in the dashboard and setup flow.

New Features:

• Introduce setup-time AI provider selection with persisted configuration in config/providers.json.
• Expose a dashboard Providers page to view, configure, activate, and test AI providers with masked secrets.
• Add backend REST endpoints to list providers, manage the active provider, update provider configuration, and test provider connectivity.

Enhancements:

• Update the terminal Claude bridge and ADW runner to resolve the active provider’s CLI (claude or openclaude) and inject provider-specific environment variables into spawned processes.
• Extend the dashboard routing and sidebar navigation to include the new Providers management page.

Documentation:

• Extend the example environment configuration to cover AI provider-related settings.

[sourcery-ai]

Reviewer's Guide

Implements multi-provider AI support by introducing a providers registry, backend API, and frontend management UI, and wiring provider-specific CLI commands and environment variables into both the terminal bridge and ADW runner while extending setup to configure providers interactively.

Sequence diagram for terminal session startup with provider-specific CLI and env vars

sequenceDiagram
  participant TerminalClient
  participant ClaudeBridge as ClaudeBridge_js
  participant ProvidersJSON as providers_json
  participant CLI as AI_CLI_binary

  TerminalClient->>ClaudeBridge: startSession(workingDir, agent, ...)
  activate ClaudeBridge
  ClaudeBridge->>ClaudeBridge: _loadProviderConfig()
  ClaudeBridge->>ProvidersJSON: read config/providers.json
  ProvidersJSON-->>ClaudeBridge: {active_provider, providers[active]}
  ClaudeBridge->>ClaudeBridge: findClaudeCommand()
  ClaudeBridge-->>TerminalClient: sessionId
  ClaudeBridge->>CLI: "spawn(claudeCommand, args, [ env = process.env + provider.env_vars + TERM,FORCE_COLOR,COLORTERM ])"
  deactivate ClaudeBridge

Loading

Sequence diagram for ADW run_claude using active provider

sequenceDiagram
  participant ADWTask as ADW_task
  participant Runner as runner_py
  participant ProvidersJSON as providers_json
  participant CLI as AI_CLI_binary

  ADWTask->>Runner: run_claude(prompt, log_name, timeout, agent)
  activate Runner
  Runner->>Runner: _get_provider_config()
  Runner->>ProvidersJSON: read config/providers.json
  ProvidersJSON-->>Runner: cli_command, env_vars
  Runner->>Runner: build cmd = [cli_command, --print, --dangerously-skip-permissions, --output-format json, optional --agent]
  Runner->>CLI: subprocess.Popen(cmd, cwd=WORKSPACE, env=os.environ + provider_env + TERM=dumb)
  CLI-->>Runner: streaming stdout/stderr
  Runner->>Runner: _log_to_file(...)
  Runner-->>ADWTask: result dict
  deactivate Runner

Loading

ER diagram for providers.json registry structure

erDiagram
  PROVIDER_REGISTRY {
    string active_provider
  }

  PROVIDER {
    string id
    string name
    string description
    string cli_command
    boolean requires_logout
    string setup_hint
    string default_model
    string default_base_url
    string default_region
  }

  ENV_VAR {
    string key
    string value
  }

  PROVIDER_REGISTRY ||--o{ PROVIDER : providers
  PROVIDER ||--o{ ENV_VAR : env_vars

Loading

File-Level Changes

Change	Details	Files
Add configurable multi-provider registry and setup-time provider selection.	Introduce config/providers.json schema with active_provider, provider definitions, CLI command, and env vars per provider. Extend setup.py with choose_provider() to select a provider, ensure openclaude is installed when required, prompt for provider-specific env vars, and persist them to providers.json. Adjust setup main() flow to run the provider selection step before collecting user info.	config/providers.json setup.py
Make terminal server sessions respect active provider CLI and env vars.	Load active provider configuration from config/providers.json at ClaudeBridge construction time, with safe defaults and logging. Resolve claude vs openclaude binary in findClaudeCommand() based on providerConfig.cli_command and update error messages accordingly. Inject provider-specific env vars into the spawned PTY process environment and support runtime reload of provider config when changed via API.	dashboard/terminal-server/src/claude-bridge.js
Make ADW runner use active provider binary and injected env vars.	Add _get_provider_config() helper to read CLI command and env vars from config/providers.json with error handling. Update run_claude() to construct the command using the configured CLI, add provider env vars to the subprocess environment, and label output with the provider CLI when not using native claude. Keep existing logging, timeout, and streaming behavior otherwise intact.	ADWs/runner.py
Expose provider management over the backend API, including masking of secrets and CLI status/testing.	Create a Flask blueprint with endpoints to list providers, get/set the active provider, get/update a provider’s env var config, and test CLI connectivity. Implement helpers to read/write providers.json, check CLI installation and version, mask secrets in env vars, and compute whether a provider is considered configured. Return overall claude/openclaude installation status alongside provider metadata for frontend consumption.	dashboard/backend/routes/providers.py
Add dashboard UI for viewing, configuring, testing, and activating providers.	Introduce Providers React page that fetches providers, shows install/config/active status, and displays per-provider cards with actions to configure, activate, and test. Implement configuration modal that edits env vars (with labels, masking, defaults) and posts updates, plus inline and modal test results using the backend test endpoint. Wire the page into the app by adding the /providers route and a Providers nav item under the System section.	dashboard/frontend/src/pages/Providers.tsx dashboard/frontend/src/App.tsx dashboard/frontend/src/components/Sidebar.tsx
Document provider-related environment configuration.	Extend .env.example with AI provider configuration examples for OpenRouter, OpenAI, Gemini, and related env vars to guide users.	.env.example dashboard/backend/app.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 5 security issues, 1 other issue, and left some high level feedback:

Security issues:

• Detected subprocess function 'Popen' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'. (link)
• Detected subprocess function 'run' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'. (link)
• Detected user input entering a subprocess call unsafely. This could result in a command injection vulnerability. An attacker could use this vulnerability to execute arbitrary commands on the host, which allows them to download malware, scan sensitive data, or run any command they wish on the server. Do not let users choose the command to run. In general, prefer to use Python API versions of system commands. If you must use subprocess, use a dictionary to allowlist a set of commands. (link)
• Detected subprocess function 'run' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'. (link)
• Detected subprocess function 'test_provider' with user controlled data. A malicious actor could leverage this to perform command injection. You may consider using 'shlex.escape()'. (link)

General comments:

• The provider registry/defaults are now defined in multiple places (checked-in config/providers.json, the setup.py fallback template, and some frontend assumptions like ENV_VAR_LABELS/PROVIDER_COLORS); consider centralizing this schema/metadata in a single source of truth to avoid future drift between installer, backend, and UI.
• ClaudeBridge caches providerConfig at construction and exposes reloadProviderConfig(), but nothing in this diff invokes it from the providers API; if provider changes are meant to apply without restarting the terminal server, consider wiring a reload call (or re-reading the config in startSession) when the active provider is updated.
• In Providers.tsx the testResult state is shared across all provider cards and the modal, which can lead to confusing UI if you test multiple providers or reopen the modal; it would be clearer to track test results per provider (e.g., keyed by provider id) or scoped to the currently interacted provider.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The provider registry/defaults are now defined in multiple places (checked-in config/providers.json, the setup.py fallback template, and some frontend assumptions like ENV_VAR_LABELS/PROVIDER_COLORS); consider centralizing this schema/metadata in a single source of truth to avoid future drift between installer, backend, and UI.
- ClaudeBridge caches providerConfig at construction and exposes reloadProviderConfig(), but nothing in this diff invokes it from the providers API; if provider changes are meant to apply without restarting the terminal server, consider wiring a reload call (or re-reading the config in startSession) when the active provider is updated.
- In Providers.tsx the testResult state is shared across all provider cards and the modal, which can lead to confusing UI if you test multiple providers or reopen the modal; it would be clearer to track test results per provider (e.g., keyed by provider id) or scoped to the currently interacted provider.

## Individual Comments

### Comment 1
<location path="dashboard/frontend/src/pages/Providers.tsx" line_range="351-352" />
<code_context>
+                  </button>
+                </div>
+
+                {/* Test result inline */}
+                {testResult && configOpen !== prov.id && testing !== prov.id && (
+                  <div className={`mt-2 text-[10px] px-2 py-1 rounded ${
+                    testResult.success
</code_context>
<issue_to_address>
**issue (bug_risk):** Single global `testResult` state is reused for all providers and can show on the wrong card.

Both the inline status and modal read from a single `testResult`, so the last test run is shown on any card matching `configOpen !== prov.id && testing !== prov.id`, regardless of which provider was actually tested. This is misleading when testing multiple providers.

Track results per provider instead, e.g. `const [testResults, setTestResults] = useState<Record<string, TestResult | null>>({})`, read `testResults[prov.id]` in the card/modal, and have `handleTest` update only the entry for the current provider ID.
</issue_to_address>

### Comment 2
<location path="ADWs/runner.py" line_range="174-178" />
<code_context>
        process = subprocess.Popen(
            cmd,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True,
            cwd=str(WORKSPACE),
            env={**os.environ, **provider_env, "TERM": "dumb"},
        )
</code_context>
<issue_to_address>
**security (python.lang.security.audit.dangerous-subprocess-use-audit):** Detected subprocess function 'Popen' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'.

*Source: opengrep*
</issue_to_address>

### Comment 3
<location path="dashboard/backend/routes/providers.py" line_range="56-59" />
<code_context>
        result = subprocess.run(
            [bin_path, "--version"],
            capture_output=True, text=True, timeout=10,
        )
</code_context>
<issue_to_address>
**security (python.lang.security.audit.dangerous-subprocess-use-audit):** Detected subprocess function 'run' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'.

*Source: opengrep*
</issue_to_address>

### Comment 4
<location path="dashboard/backend/routes/providers.py" line_range="236-240" />
<code_context>
        result = subprocess.run(
            [bin_path, "--version"],
            capture_output=True, text=True, timeout=15,
            env=test_env,
        )
</code_context>
<issue_to_address>
**security (python.flask.security.injection.subprocess-injection):** Detected user input entering a `subprocess` call unsafely. This could result in a command injection vulnerability. An attacker could use this vulnerability to execute arbitrary commands on the host, which allows them to download malware, scan sensitive data, or run any command they wish on the server. Do not let users choose the command to run. In general, prefer to use Python API versions of system commands. If you must use subprocess, use a dictionary to allowlist a set of commands.

*Source: opengrep*
</issue_to_address>

### Comment 5
<location path="dashboard/backend/routes/providers.py" line_range="236-240" />
<code_context>
        result = subprocess.run(
            [bin_path, "--version"],
            capture_output=True, text=True, timeout=15,
            env=test_env,
        )
</code_context>
<issue_to_address>
**security (python.lang.security.audit.dangerous-subprocess-use-audit):** Detected subprocess function 'run' without a static string. If this data can be controlled by a malicious actor, it may be an instance of command injection. Audit the use of this call to ensure it is not controllable by an external resource. You may consider using 'shlex.escape()'.

*Source: opengrep*
</issue_to_address>

### Comment 6
<location path="dashboard/backend/routes/providers.py" line_range="237" />
<code_context>
            [bin_path, "--version"],
</code_context>
<issue_to_address>
**security (python.lang.security.dangerous-subprocess-use):** Detected subprocess function 'test_provider' with user controlled data. A malicious actor could leverage this to perform command injection. You may consider using 'shlex.escape()'.

*Source: opengrep*
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}