fix(cli): avoid default env overrides for profiles

[Sskift]

Summary

• stop exporting dispatcher-resolved default provider/model/base URL as TUI env overrides
• keep explicit CLI provider/model/base URL flags working as intentional overrides
• add regression coverage for profile startup handoff and explicit override behavior

Closes #2114

Verification

• cargo fmt --all --check
• git diff --check
• cargo test -p codewhale-cli build_tui_command
• cargo check -p codewhale-cli

Greptile Summary

This PR fixes a bug where the CLI dispatcher-resolved defaults (model, base_url, provider, auth_mode, http_headers) were unconditionally exported as environment variables when spawning the TUI, causing them to override profile-specific settings loaded by the TUI itself. The fix narrows handoff to only explicit CLI flags and keyring-sourced secrets.

• Resolved runtime values (model, base_url, auth_mode, http_headers) are no longer injected as env overrides; the TUI now reads these from its own profile/config merge.
• The keyring path is preserved: when the API key came from the platform keyring, the secret and source tag are still bridged because the TUI does not re-query the keyring on startup.
• New regression tests cover profile startup handoff (no stray overrides) and explicit override forwarding.

Confidence Score: 4/5

Safe to merge for the profile-override regression, but the explicit --api-key path drops provider-specific key vars for most providers.

The core fix is correct and well-tested. However, the new cli.api_key block manually enumerates only Openai, Atlascloud, and WanjieArk (partially) instead of using provider_env_vars(). Anyone who passes --provider moonshot --api-key or any of the other eight supported providers will have their provider-specific env var missing in the TUI process, which is a regression from the previous code that used provider_env_vars() for all sources.

crates/cli/src/lib.rs — specifically the cli.api_key forwarding block (lines 1512–1524)

Important Files Changed

Filename

Overview

crates/cli/src/lib.rs

Correctly stops forwarding dispatcher-resolved defaults as TUI env overrides; keyring and explicit-flag paths are sound. However, the new cli.api_key block manually enumerates only three providers instead of calling provider_env_vars(), leaving Moonshot, NvidiaNim, Openrouter, Novita, Fireworks, SGLang, vLLM, and Ollama without their provider-specific key env vars when --api-key is passed explicitly.

Sequence Diagram

sequenceDiagram
    participant User
    participant CLI as codewhale CLI
    participant Dispatcher as Config Dispatcher
    participant TUI as codewhale TUI

    User->>CLI: deepseek --profile google
    CLI->>Dispatcher: resolve runtime options
    Dispatcher-->>CLI: ResolvedRuntimeOptions(provider, model, base_url, auth_mode, api_key)

    Note over CLI: OLD: forwarded all resolved values as env overrides
    Note over CLI: NEW: only forwards explicit CLI flags

    alt explicit --provider flag
        CLI->>TUI: DEEPSEEK_PROVIDER injected
    end
    alt explicit --model flag
        CLI->>TUI: DEEPSEEK_MODEL injected
    end
    alt explicit --base-url flag
        CLI->>TUI: DEEPSEEK_BASE_URL injected
    end
    alt api_key_source is Keyring
        CLI->>TUI: "API key env vars + source=keyring injected"
    end
    alt explicit --api-key flag
        CLI->>TUI: "API key env vars + source=cli injected"
    end

    CLI->>TUI: --profile google passed as arg
    TUI->>TUI: reads profile config for model, base_url, auth_mode

Loading

Comments Outside Diff (1)

1. crates/cli/src/lib.rs, line 1512-1524 (link)

   Missing provider_env_vars() in the --api-key CLI path leaves provider-specific keys unset for the TUI. Providers like Moonshot (MOONSHOT_API_KEY, KIMI_API_KEY), NvidiaNim (NVIDIA_API_KEY, NVIDIA_NIM_API_KEY), Openrouter, Novita, Fireworks, SGLang, vLLM, and Ollama are all skipped — only DEEPSEEK_API_KEY is forwarded. Even the WanjieArk case is incomplete: provider_env_vars returns three vars (WANJIE_ARK_API_KEY, WANJIE_API_KEY, WANJIE_MAAS_API_KEY) but only the first is set. The keyring path uses provider_env_vars() correctly; this path should match it.

   

_{Reviews (3): Last reviewed commit: "test(cli): restore prompt flag coverage" | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request modifies the build_tui_command function to prevent the CLI from unconditionally overriding TUI environment variables with global defaults, specifically for the provider, model, and base URL. This change ensures that profile-specific configurations are respected unless explicitly overridden by CLI flags. New tests have been added to verify these isolation improvements. A review comment suggests that similar conditional logic should be applied to DEEPSEEK_API_KEY and DEEPSEEK_HTTP_HEADERS to ensure full profile isolation and consistency across all runtime options.

[Sskift]

Updated in 4f5a350b to address this.

What changed:

• removed unconditional DEEPSEEK_HTTP_HEADERS export from dispatcher-resolved runtime options, so base/profile headers are loaded by the TUI config path instead of being replayed as env overrides
• narrowed resolved API key bridging to keyring-sourced secrets only; config-file keys are no longer exported as DEEPSEEK_API_KEY, while the existing explicit --api-key path still exports the CLI override later in build_tui_command
• extended the profile handoff regression test to assert resolved config-file keys and headers are not exported

Kept keyring bridging intentionally, because the TUI does not re-query platform credential stores on normal config load and still needs the dispatcher-recovered secret handoff.

Verification rerun:

• cargo fmt --all --check
• git diff --check
• cargo test -p codewhale-cli build_tui_command
• cargo check -p codewhale-cli