[Critical] When settings.model.name is set but does not match any configured provider, this loop falls through to OPENAI_MODEL / QWEN_MODEL and passes that env-matched modelProvider into resolveModelConfig. Core resolution still prioritizes modelProvider over settings, so the env provider overrides the configured settings model entirely. A user with settings.model.name = "custom-model" and a leftover OPENAI_MODEL matching a provider can unexpectedly run the env/provider model instead of the settings-selected model.

Please only use env-based provider lookup when neither argv.model nor settings.model.name is set, or adjust the resolver call so an env-matched provider can supply metadata without overriding the higher-precedence model. Also add an unmocked/integration test for settings.model.name unmatched + OPENAI_MODEL matched.

— gpt-5.5 via Qwen Code /review

Fixed in latest push — the old candidate-loop is gone. Model is now resolved via strict precedence (argv > settings > env), and modelProvider is looked up separately based on resolvedModel. No fallthrough to OPENAI_MODEL anymore.

[Critical] When settings.model.name is set but does not match any configured provider, this loop falls through to OPENAI_MODEL / QWEN_MODEL and passes that env-matched modelProvider into resolveModelConfig. Core resolution still prioritizes modelProvider over settings, so the env provider overrides the configured settings model entirely. A user with settings.model.name = "custom-model" and a leftover OPENAI_MODEL matching a provider can unexpectedly run the env/provider model instead of the settings-selected model.

Please only use env-based provider lookup when neither argv.model nor settings.model.name is set, or adjust the resolver call so an env-matched provider can supply metadata without overriding the higher-precedence model. Also add an unmocked/integration test for settings.model.name unmatched + OPENAI_MODEL matched.

— gpt-5.5 via Qwen Code /review

Same as above — the old loop is gone. Model resolved via strict precedence now.

[Critical] This mock returns sources.model as a string, but resolveModelConfig is typed to return ModelConfigResolutionResult, whose sources values must be ConfigSource objects. As written, npm run typecheck fails on this mock implementation, so the PR cannot pass the TypeScript build gate.

— gpt-5.5 via Qwen Code /review

Fixed in 1353d21 - updated the mock to return proper ConfigSource objects with kind, path, and envKey fields matching the reviewer's suggestion. Also added [Regression] tests (5 tests) guarding against the original model precedence bug.

[Suggestion] This regression test does not actually assert that OPENAI_MODEL is ignored. The resolveModelConfig mock returns claude-3 unconditionally, and the test only checks result.model, so it would still pass if resolveCliGenerationConfig incorrectly passed OPENAI_MODEL through to the resolver for Anthropic auth.

— gpt-5.5 via Qwen Code /review

[Critical] This only derives resolvedModel from env for OpenAI auth. For USE_ANTHROPIC, USE_GEMINI, or USE_VERTEX_AI, core still supports auth-specific model env vars (ANTHROPIC_MODEL, GEMINI_MODEL, GOOGLE_MODEL), but this CLI-side provider lookup now skips them entirely when settings.model.name is unset. That means a matching modelProviders[authType] entry will not be passed to resolveModelConfig, so provider metadata such as envKey, baseUrl, and generationConfig can be lost for non-OpenAI env-selected models.

Please resolve env fallback by selected auth type instead of hard-coding OpenAI here, reusing the same env model mapping as core resolution while still preserving the new argv/settings precedence.

— gpt-5.5 via Qwen Code /review

Fixed — AUTH_ENV_MODEL_VARS mapping now covers all auth types (USE_OPENAI, USE_GEMINI, USE_VERTEX_AI, USE_ANTHROPIC). Env resolution iterates only the env vars for the current authType.

[Suggestion] The filtering decision is based on value equality instead of the source that actually selected the model. If settings.model.name happens to equal OPENAI_MODEL, this keeps OPENAI_MODEL in filteredEnv; since core resolves model as modelProvider > cli > env > settings, an unmatched settings-selected model can then be attributed to env rather than settings. That weakens the precedence fix for source-aware downstream behavior.

— gpt-5.5 via Qwen Code /review

Fixed — filtering now uses sourceEnvVar (source-based), not value equality. sourceEnvVar is only set when model was resolved from an env var. If model came from argv or settings, sourceEnvVar is undefined and ALL model env vars are stripped.

[Critical — root cause exposed here] This model: undefined is a per-test workaround for the new strip-path side effect, and it leaves the sibling test should use process.env when env is not provided (line 568) silently exposed to the same problem.

That sibling test still uses the default makeMockSettings() (which sets model: { name: 'default-model' }), so the strip path triggers and a filtered env is passed to resolveModelConfig — breaking the env: process.env assertion. Reproduction:

OPENAI_MODEL=ci-leak-model OPENAI_API_KEY=fake OPENAI_BASE_URL=http://x \
  npx vitest run src/utils/modelConfigUtils.test.ts
# Tests  1 failed | 40 passed

This is the same failure signature that #3633 rolled back from #3567 (run 24949085749). CI passes only because CI doesn't export OPENAI_MODEL — but the user cohort this PR is targeting is exactly developers with leftover OPENAI_MODEL in their shell.

Suggested fix: instead of patching individual tests with model: undefined, sanitize once in beforeEach so the whole suite is decoupled from the developer's shell:

beforeEach(() => {
  vi.resetModules();
  process.env = { ...originalEnv };
  delete process.env['OPENAI_MODEL'];
  delete process.env['QWEN_MODEL'];
  mockWriteStderrLine.mockClear();
});

Then the model: undefined here can be reverted, and future tests don't need the workaround either.

[Cleanup] Stray // trigger rebuild comment leftover from CI debugging. Please remove before merge.

[Critical] The new precedence logic applies settings.model.name ahead of the auth-specific model environment variable for every auth type, not just OpenAI. When selectedAuthType is inferred from env, for example GEMINI_API_KEY + GEMINI_MODEL, a stale persisted settings.model.name now wins over GEMINI_MODEL.

This can send a settings model from one provider to a newly selected provider when users switch auth via environment variables. Please restrict the new settings.model.name > OPENAI_MODEL > QWEN_MODEL precedence override to AuthType.USE_OPENAI, or otherwise preserve the existing env-over-settings behavior for non-OpenAI auth types.

— gpt-5.5 via Qwen Code /review

Intentional — PR title and description state precedence applies to all auth types. AUTH_ENV_MODEL_VARS resolves correct env vars per authType. Non-OpenAI auth now correctly ignores OPENAI_MODEL (see Edge Case 4 test).

[Critical] This cleanup only removes OPENAI_MODEL and QWEN_MODEL, but the production code now filters all auth-specific model env vars (ANTHROPIC_MODEL, GEMINI_MODEL, and GOOGLE_MODEL too). If any of those are present in a developer or CI environment, should use process.env when env is not provided fails because resolveCliGenerationConfig passes a filtered env while the test still expects the full process.env.

— gpt-5.5 via Qwen Code /review