Codex review: needs maintainer review before merge. Reviewed June 3, 2026, 12:48 PM ET / 16:48 UTC.

Summary
The PR adds stale auto runtime auth/model detection and routes run selection, preflight, display, and child-session inheritance through selected-model handling instead of blindly trusting persisted runtime fallback fields.

PR surface: Source +355, Tests +1128. Total +1483 across 15 files.

Reproducibility: yes. Current main source shows persisted runtime model fields win in resolveSessionModelRef and are inherited by sessions.create; the PR’s fixtures encode the stale auto-fallback shapes that cause the wrong selected/active model behavior.

Review metrics: 1 noteworthy metric.

• Persisted session fields cleared: 10 fields. The stale auto-runtime repair can delete this clear-list from existing session rows, so maintainers should inspect the compatibility boundary before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Get explicit maintainer acceptance of the stale predicate and cleared-field list before marking the draft ready.

Risk before merge

• [P2] The stale repair can delete existing persisted runtime/auth/context/fallback-notice fields; an overbroad predicate would change provider or auth selection after upgrade.
• [P1] The PR intentionally keeps a split between generic runtime identity and next-run selected model resolution; maintainers should accept that narrow split while the broader resolver cleanup remains in Refactor session model/auth state resolution #87957.
• [P2] Proof is strong synthetic coverage plus reported AWS Crabbox changed-gate output, but it does not include live MiniMax/DeepSeek or equivalent forced provider fallback with real credentials.

Maintainer options:

1. Accept the narrow repair (recommended)
   A maintainer can approve the stale predicate and clear-list semantics as the intended bug fix, with the broader resolver consolidation left to the open follow-up issue.
2. Consolidate before merge
   If maintainers do not want an interim resolver split, ask for the PR to move more raw session interpretation behind one canonical resolver before merge.
3. Require live fallback proof
   If synthetic fixtures are not enough for this auth/provider risk, ask for redacted live provider fallback proof before approving.

Next step before merge

• [P2] Human maintainer review is the next action because the PR is draft/protected and intentionally changes persisted auth/session fallback semantics without a concrete automated repair finding.

Security
Cleared: No supply-chain, dependency, workflow, or secret-handling regression was found; auth-provider behavior risk is tracked as merge risk rather than a concrete security defect.

Implementation report for current head dff39e50a0e3c9a92fa93f041e01696830b2be23.

Summary:

• Repairs stale auto-owned runtime auth fallback state by comparing runtime provider/model against the effective expected selection before trusting it.
• Prevents new dashboard/WebChat child sessions from inheriting stale parent fallback runtime/auth/context fields.
• Preserves explicit /model directives, healthy auto auth profile rotation, inherited parent/channel model selections, and runtime-equivalent OpenAI/OpenAI Codex aliases.
• No new config value and no plugin/SDK interface change.

Review/comment handling:

• The stale inline review about over-broad auto auth cleanup was addressed and the review thread is resolved.
• The older ClawSweeper display/read-path finding was addressed by routing the generic session model resolver back through runtime-preserving behavior plus stale-state comparison against the effective model, with gateway/session regressions added.
• Latest local review command reported no actionable correctness issues.

Validation:

• git diff --check passed.
• node scripts/run-vitest.mjs src/sessions/model-overrides.test.ts src/auto-reply/reply/model-selection.test.ts src/gateway/session-utils.test.ts src/gateway/server.sessions.create.test.ts passed: 6 files, 377 tests.
• node scripts/run-vitest.mjs src/auto-reply/reply/agent-runner-execution.test.ts -t "auto fallback" passed: 2 tests.
• codex review --base main completed with no actionable correctness issues. Its sandbox test attempt hit listen EPERM: operation not permitted 127.0.0.1 for the gateway server suite; the same focused gateway suite passed locally through the repo test wrapper.
• AWS Crabbox/Testbox-style broad gate passed on current head: node scripts/crabbox-wrapper.mjs run --provider aws --idle-timeout 90m --ttl 240m --timing-json --shell -- $'git fetch origin +main:refs/remotes/origin/main --deepen=1000\ngit fetch origin --deepen=1000\npnpm check:changed'; provider aws, lease cbx_fe5a8403f937, run run_2badb5cd84a0, exit 0.

CI state checked:

• Relevant CI checks for the changed core/gateway/auth/session surfaces are passing.
• Remaining red checks-windows-node-test failed during checkout before tests ran: fatal: fetch-pack: invalid index-pack output, exit 124. I classify this as runner/checkout infrastructure, not patch behavior.
• Remaining red Scan changed paths (precise) reports src/gateway/server-discovery-runtime.test.ts, which is not in this PR diff. I classify this as unrelated to this patch.

Behavior addressed: stale auto-owned runtime auth fallback state no longer pins a session or child session to the fallback provider when the configured/effective selected model is different.
Real environment tested: local repo wrapper tests on this worktree; AWS remote changed gate on provider aws, lease cbx_fe5a8403f937, run run_2badb5cd84a0.
Exact steps or command run after this patch: focused Vitest commands above; git diff --check; codex review --base main; AWS pnpm check:changed command above.
Evidence after fix: focused synthetic regressions pass for MiniMax/DeepSeek stale fallback repair, legacy compaction-count provenance, healthy auto auth rotation, explicit model directive preservation, inherited parent/channel selection, child session inheritance, and OpenAI/OpenAI Codex runtime aliases; broad changed gate passes on AWS.
Observed result after fix: stale runtime/auth/context/fallback-notice fields are cleared only for auto-owned stale runtime selections, and normal explicit or healthy auto selections are preserved.
What was not tested: live MiniMax/DeepSeek provider fallback with real credentials; no live WebChat/TUI visual proof was run in this session.

@clawsweeper re-review

The display/read-path finding has been addressed in fe055af5a248377093f566342e077b76dfc49177.

The row/display resolver now ignores stale auto runtime auth state through the shared stale predicate, and src/gateway/session-utils.test.ts includes a MiniMax/DeepSeek row-display regression proving stale DeepSeek runtime metadata displays the configured MiniMax primary.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26627220451
• Updated: 2026-05-29T08:45:36.626Z

@clawsweeper re-review

Follow-up cleanup pushed in 2402271 after maintainer review of code smells.

Changed only source shape, not behavior:

• Named the stale runtime/auth and expected-model session entry shapes instead of repeating large Pick<SessionEntry, ...> types.
• Added shared resolveSessionExpectedSelectedModelRef for default/model-override/channel-selected expected model calculation.
• Reused that helper from sessions.create inheritance instead of duplicating channel override parsing there.
• Moved stale clear fields into a typed field list and documented the legacy compaction-count provenance marker.
• Added a short comment distinguishing generic runtime model resolution from next-run dispatch/preflight model resolution.

Proof run after the cleanup:

• ./node_modules/.bin/oxfmt --write --threads=1 src/sessions/model-overrides.ts src/gateway/session-utils.ts src/gateway/server-methods/sessions.ts
• ./node_modules/.bin/oxlint src/sessions/model-overrides.ts src/sessions/model-overrides.test.ts src/gateway/session-utils.ts src/gateway/session-utils.test.ts src/gateway/server-methods/sessions.ts src/gateway/server.sessions.create.test.ts src/gateway/server-methods/chat.ts src/gateway/server.chat.gateway-server-chat-b.test.ts src/auto-reply/reply/model-selection.ts src/auto-reply/reply/model-selection.test.ts
• git diff --check
• node scripts/run-vitest.mjs src/gateway/session-utils.test.ts src/gateway/server.sessions.create.test.ts src/gateway/server.chat.gateway-server-chat-b.test.ts src/sessions/model-overrides.test.ts src/auto-reply/reply/model-selection.test.ts passed: 3 Vitest shards, 5 files, 229 tests.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26830666689
• Updated: 2026-06-02T15:47:28.837Z

@clawsweeper re-review

Please rerun on current head 24022718cb5bb1d88a2534dd4688c2bbc230741d.

The previous targeted re-review failed at the ClawSweeper/Codex workflow layer and did not report a patch finding. The cleanup commit only refactored the session expected-model helper shape; focused proof passed in the prior comment.

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

Re-review progress:

• State: Failed
• Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26828737442
• Updated: 2026-06-02T15:17:42.899Z

Related variant: stale entry.model/entry.modelProvider persist when /model selects the config default

@osolmaz I hit the same bug class (stale runtime fallback state) but from a different angle — model overrides only, no auth profile involved.

What I observed

1. Primary opencode-go/qwen3.6-plus failed during a run (session file locked during CLI compaction → timeout).
2. Auto-fallback to opencode-go/deepseek-v4-pro succeeded. The gateway persisted:

   entry.model = "deepseek-v4-pro"
   entry.modelProvider = "opencode-go"
   modelOverrideSource = "auto"  (then later cleared)
   

3. Gateway restarted. Session store still had model/modelProvider pointing at deepseek.
4. Running /model opencode-go/qwen3.6-plus (which is the configured agents.defaults.model.primary) should have cleared the stale runtime fields, but the status card still showed:
   • Selected: opencode-go/qwen3.6-plus ✅
   • Active: opencode-go/deepseek-v4-pro ❌
   • No modelOverride or modelOverrideSource persisted (both were deleted because the selection matched the config default → isDefault: true)

Root cause in applyModelOverrideToSessionEntry

The isDefault branch deletes override fields (providerOverride, modelOverride, modelOverrideSource, fallback origin) but does not clear stale runtime entry.model / entry.modelProvider:

if (selection.isDefault) {
    if (entry.providerOverride) { delete entry.providerOverride; ... }
    if (entry.modelOverride) { delete entry.modelOverride; ... }
    if (entry.modelOverrideSource) { delete entry.modelOverrideSource; ... }
    // ← MISSING: stale runtime model/modelProvider are not cleared here
}

The non-default branch does clear them:

const runtimeAligned = runtimeModel === selection.model && ...;
if (runtimePresent && (selectionUpdated || !runtimeAligned)) {
    if (entry.model !== undefined) { delete entry.model; updated = true; }
    if (entry.modelProvider !== undefined) { delete entry.modelProvider; updated = true; }
}

But this block only runs in the else branch (when !selection.isDefault), so it is skipped entirely when the user selects the config default.

Why the display is wrong

resolveSessionModelIdentityRef() (used by the status card) reads entry.model / entry.modelProvider first, before falling back to config:

const runtimeModel = entry?.model?.trim();
const runtimeProvider = entry?.modelProvider?.trim();
if (runtimeModel) return { provider: runtimeProvider, model: runtimeModel };
// ... only falls back to config if runtime fields are absent

So the stale entry.model = "deepseek-v4-pro" wins over the config default, even though no override is persisted.

Reproduction steps

1. Configure agents.defaults.model.primary = "provider-a/model-a" with a fallback to "provider-b/model-b".
2. Send a message. provider-a/model-a fails (rate limit, timeout, or any failover-worthy error).
3. Auto-fallback succeeds — session now has entry.model = "model-b", entry.modelProvider = "provider-b".
4. Run /model provider-a/model-a (select the config default).
5. Run /status or session_status → Active shows provider-b/model-b instead of provider-a/model-a.
6. sessions.json for that session: no modelOverride, no modelOverrideSource, but stale model/modelProvider still point at the fallback.

Evidence from journalctl

21:32:07 [model-fallback/decision] candidate_failed requested=opencode-go/qwen3.6-plus candidate=opencode-go/qwen3.6-plus reason=unknown next=opencode-go/deepseek-v4-pro
21:33:39 [model-fallback/decision] candidate_succeeded requested=opencode-go/qwen3.6-plus candidate=opencode-go/deepseek-v4-pro reason=unknown next=none

Why this matters

• The status card becomes misleading — users cannot tell if the config default or a stale fallback is actually running.
• Unlike the auth-profile variant, there is no modelOverrideSource to signal "this was auto-selected." After the user selects the default, it becomes null, so hasSessionAutoModelFallbackProvenance() also returns false (no fallback origin fields survived either).
• The session silently carries stale runtime fields across gateway restarts.

Suggested fix

In the isDefault branch of applyModelOverrideToSessionEntry, also clear stale entry.model and entry.modelProvider when they do not match the default selection — the same logic the non-default branch already has.

@clawsweeper re-review

Addressed the latest review feedback in b0d73d7333.

Changes:

• agent.run now uses resolveSessionNextRunModelRef for attachment/image preflight.
• agent.request node events now use resolveSessionNextRunModelRef for attachment/image preflight.
• Added regressions for stale auto runtime/auth metadata on both sibling preflight paths.
• Added a regression for the related no-auth /model default-selection shape: stale runtime model / modelProvider fields are cleared when selecting the configured default.

Proof run after the patch:

• ./node_modules/.bin/oxfmt --write --threads=1 src/gateway/server-methods/agent.ts src/gateway/server-node-events.ts src/gateway/server-node-events.runtime.ts src/gateway/server.agent.gateway-server-agent-a.test.ts src/gateway/server-node-events.test.ts src/sessions/model-overrides.test.ts
• ./node_modules/.bin/oxlint src/gateway/server-methods/agent.ts src/gateway/server-node-events.ts src/gateway/server-node-events.runtime.ts src/gateway/server.agent.gateway-server-agent-a.test.ts src/gateway/server-node-events.test.ts src/sessions/model-overrides.ts src/sessions/model-overrides.test.ts
• git diff --check
• node scripts/run-vitest.mjs src/gateway/server.agent.gateway-server-agent-a.test.ts src/gateway/server-node-events.test.ts src/gateway/server.chat.gateway-server-chat-b.test.ts src/gateway/session-utils.test.ts src/sessions/model-overrides.test.ts passed: 2 Vitest shards, 5 files, 211 tests.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26899177792
• Updated: 2026-06-03T16:48:45.021Z

Fresh current-release signal from a real Discord-backed install (not after-fix proof for this PR branch): I am still seeing the same stale auto runtime auth-selection failure class on OpenClaw 2026.6.1 (2e08f0f).

Setup shape, sanitized:

• primary model/provider: openai/gpt-5.5
• same-provider auth profiles: one primary/business OpenAI profile plus two personal/emergency OpenAI fallback profiles
• affected sessions: existing Discord-backed sessions; no user auth-profile lock was set
• persisted state shape observed: authProfileOverrideSource: "auto", provider: "openai", model: "gpt-5.5", with the override pointing at a personal/emergency OpenAI profile
• the configured primary OpenAI auth profile was available at scan time

Fresh observation:

• scanner saw 10 session-store entries checked
• auto emergency auth-profile pins: 2
• non-auto/user emergency auth-profile pins: 0
• the primary profile was available in the affected store
• a dry-run recovery that only clears authProfileOverrideSource == "auto" would clear one older auto emergency pin and temporarily skip one very recent auto emergency pin

Why this seems relevant to #87893:

• this is not a cross-provider MiniMax/DeepSeek-only case; it also happens with same-provider OpenAI auth profiles
• the bad state is not a user pin; the source is auto
• the local recovery workaround has to treat the auto auth selection as transient runtime state and remove it from durable session state once the primary profile is healthy
• the observed behavior matches the self-reinforcing/stale auto runtime auth state class that this PR is trying to repair

Caveat: I have not run this PR branch in a clean stage yet, so this comment is current-release failing evidence, not a verified after-fix result for b0d73d7. If useful, I can try to produce a public-safe staged before/after proof against this branch next.