Summary 📌 required

/model <default> silently fails when the session is currently running a non-default model. Strip isDefault from model selections in directive-handling paths so user-requested model switches always write an explicit override.

• Problem: When a session runs a non-default model (via prior /model, fallback, or steering) and the user types /model <default>, the selection gets isDefault=true. This clears overrides in applyModelOverrideToSessionEntry instead of writing them, leaving the session pinned to the stale runtime model.
• Solution: Strip the isDefault flag from ModelDirectiveSelection before passing it to applyModelOverrideToSessionEntry in the two directive-handling call sites. Keep isDefault on the selection object for display/sorting purposes.
• What changed: src/auto-reply/reply/directive-handling.impl.ts (+8/-1), src/auto-reply/reply/directive-handling.persist.ts (+4/-1), src/sessions/model-overrides.test.ts (+32 regression test)
• What did NOT change: applyModelOverrideToSessionEntry itself, repair/cleanup paths (agent-command, model-selection reset, repairProviderWrappedModelOverride), isDefault display semantics in model picker/suggestions

Change Type (select all) 📌 required

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all) 📌 required

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR 📌 required

• Related to Bug: /model silently fails when switching to default model while running a different model #96269
• This PR fixes a bug or regression

Motivation 📌 required

When a session is running a non-default model (set via /model, fallback, or steering) and the user explicitly issues /model <default-model>, the session should switch to the configured default model. Instead, the switch silently fails because isDefault=true causes applyModelOverrideToSessionEntry to clear overrides rather than writing the default as an explicit override. The session remains on the old model with no error or feedback.

This is a regression in behaviour — prior versions handled this correctly because the model-override path did not distinguish between "explicit user selection" and "system reset to default."

Real behavior proof (required for external PRs) 📌 required

• Behavior addressed: /model <default> switching to the configured default model when the session is currently running a different model
• Real environment tested: Linux 4.19, Node 22.19, branch fix/model-default-switch-96269
• Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/sessions/model-overrides.test.ts --run
node scripts/run-vitest.mjs src/auto-reply/reply/directive-handling.model.test.ts src/auto-reply/reply/model-selection.test.ts --run

• Evidence after fix:

$ node scripts/run-vitest.mjs src/sessions/model-overrides.test.ts --run
[test] starting test/vitest/vitest.unit-fast.config.ts
 RUN  v4.1.8
 Test Files  1 passed (1)
      Tests  10 passed (10)
   Start at  17:50:42
   Duration  488ms

$ node scripts/run-vitest.mjs src/auto-reply/reply/directive-handling.model.test.ts src/auto-reply/reply/model-selection.test.ts --run
[test] starting test/vitest/vitest.auto-reply.config.ts
 RUN  v4.1.8
 Test Files  2 passed (2)
      Tests  132 passed (132)
   Start at  17:50:58
   Duration  18.37s

• Observed result after fix:

  1. New regression test "writes default model override when selected without isDefault flag (Bug: /model silently fails when switching to default model while running a different model #96269)" passes — verifies that when the configured default model is selected without isDefault, the override is written even when the session currently has a non-default override
  2. All 9 existing tests continue to pass — no regression in isDefault=true clearing behaviour for repair/cleanup paths
  3. All 132 directive-handling and model-selection tests pass — no regression in the /model command resolution pipeline

• What was not tested:

  • End-to-end webchat /model roundtrip with a live gateway (requires real provider credentials)
  • The isDefault display behaviour in the model picker UI (the flag is preserved on the selection object for display)

Root Cause (if applicable) ✅ optional

In resolveModelSelectionFromDirective (directive-handling.model-selection.ts), when the user types /model <default-model>, the resolved ModelDirectiveSelection carries isDefault: true because the selected model matches the configured agents.defaults.model.primary. This flag flows to applyModelOverrideToSessionEntry, where the isDefault branch unconditionally clears provider/model overrides — even when the session is currently running a different model. Clearing overrides leaves the session pinned to the stale runtime model without triggering a switch.

The fix strips isDefault before the selection reaches applyModelOverrideToSessionEntry, so user-initiated model switches always write an explicit override. The isDefault flag is preserved on the modelSelection object for display purposes (model picker sorting, switch event messages).

Regression Test Plan (if applicable) ✅ optional

Added model-overrides.test.ts: "writes default model override when selected without isDefault flag (#96269)" — verifies that a selection matching the configured default without the isDefault flag writes providerOverride and modelOverride even when the session entry currently holds a different override.

User-visible / Behavior Changes 📌 required

/model <default> now correctly switches the session to the configured default model when the session is currently running a non-default model. Previously the switch silently failed — /status would still show the old model with no error feedback.

Diagram (if applicable) ✅ optional

Before (broken):
  Session runs: tencent/glm-5.1 (override)
  User types:   /model minimax/MiniMax-M3  (configured default)
  isDefault=true → applyModelOverrideToSessionEntry clears overrides
  Session stays: tencent/glm-5.1  ← BUG: no switch, no error

After (fixed):
  Session runs: tencent/glm-5.1 (override)
  User types:   /model minimax/MiniMax-M3  (configured default)
  isDefault stripped → applyModelOverrideToSessionEntry writes override
  Session now:  minimax/MiniMax-M3  ← CORRECT

Security Impact (required) 📌 required

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification ✅ optional

Environment

• OS: Linux 4.19.112-2.el8
• Runtime/container: Node 22.19
• Model/provider: N/A (unit-test verified)
• Integration/channel: N/A (directive-handling path)

Steps

1. Configure agents.defaults.model.primary: "minimax/MiniMax-M3"
2. Switch session to a different model: /model tencent-token-plan/glm-5.1
3. Switch back to default: /model minimax/MiniMax-M3
4. Check /status — should show minimax/MiniMax-M3

Expected

Session switches to minimax/MiniMax-M3.

Actual (before fix)

Session stays on tencent-token-plan/glm-5.1. No error or feedback.

Human Verification (required) 📌 required

• Verified scenarios: Unit test covers the exact scenario from Bug: /model silently fails when switching to default model while running a different model #96269 (session with non-default override, user selects default model without isDefault flag)
• Edge cases checked: existing isDefault=true clearing behaviour preserved for repair/cleanup paths; test for isDefault=true with already-matching override still clears correctly
• What you did NOT verify: Live webchat end-to-end /model roundtrip

Compatibility / Migration 📌 required

• Backward compatible? Yes — no API or config changes
• Config/env changes? No
• Migration needed? No

Best-fix Verdict 📌 required (from Review Contract)

• Best fix: Yes — stripping isDefault at the directive-handling boundary is the right fix because:
  1. It separates the display concern (isDefault for model picker sorting) from the behavioural concern (explicit model switch)
  2. It does not modify applyModelOverrideToSessionEntry, preserving existing semantics for repair/cleanup paths
  3. The fix boundary matches the intent boundary: user-requested model selections should always write explicit overrides
• Refactor needed: No
• Alternative considered:
  • Fix applyModelOverrideToSessionEntry isDefault branch: Adding a hasNonDefaultOverride check inside the callee would also work, but it would change behaviour for all callers including repair/cleanup paths where clearing is the correct intent. The callee lacks enough context to distinguish user-initiated switches from system-initiated cleanup.
  • Remove isDefault from resolveModelDirectiveSelection: Would affect model picker display/sorting since isDefault is consumed downstream for UI purposes.

AI Assistance 🤖 (required for AI-assisted PRs)

• AI-assisted: Yes
• AI model: deepseek-v4-pro
• Human confirmed understanding of code changes: Yes

Risks and Mitigations 📌 required

• Highest-risk area: Existing sessions that rely on isDefault=true clearing behaviour from the directive-handling path. Previously, if a user typed /model <default> while already on the default model, overrides would be cleared (no-op since none existed). Now an explicit override is written. This is a semantic change but the practical effect is identical — the session runs the default model either way.
• Mitigation: The override values written match the configured default model, so session behaviour is unchanged. If the config default later changes, this session retains its explicit override (which is the correct behaviour for a user who explicitly selected a model).
• Compatibility impact: None. No config, API, or storage format changes.

Related to #96269