Repository navigation
[Bug]: After a Claude safeguard fallback, the thread keeps the original model, so the composer is wrong and resumes switch back #24115
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- In T3 Code, start a thread on the Claude provider with
claude-opus-5-5. - Send a message that the safeguards classifier flags (any
[cyber]false positive works). - Let the CLI move the session to the fallback model. With the default
switchModelsOnFlag: trueit switches on its own. Withfalseit does so after you choose "Retry with Claude Opus 4.8" (fix(claude): ask before retrying a flagged message on the fallback model #24044). - Look at the composer's model picker, then send a follow-up after the provider session restarts (server restart, idle, or compaction).
Expected behavior
The thread follows the model the CLI moved the session to. The composer shows Claude Opus 4.8, a resumed session opens on Opus 4.8, and picking another model in the composer still works.
Actual behavior
The turn runs on Opus 4.8 and T3 shows the notice from #8853 ("Switched to Opus 4.8"), but the thread's model selection stays claude-opus-5-5:
- The composer keeps showing Claude Opus 5.5 while the session is actually on Opus 4.8.
- The next resume opens the session with
model: "claude-opus-5-5"again, so the next message goes back to the model that flagged it.
Root cause: ClaudeAdapterV2 handles the system/model_refusal_fallback message only as a system_notice turn item. It doesn't update the live query's selection or the thread's modelSelection. The adapter only calls setModel when the thread selection differs from the selection it believes the live query has, so after a fallback T3's state and the CLI's session model disagree until the session is reopened.
The SDK message already carries what T3 needs (@anthropic-ai/claude-agent-sdk 0.3.276, SDKModelRefusalFallbackMessage): fallback_model, original_model, direction (retry | revert | sticky) and scope, where 'session' means "the main thread fell back and the session model is swapped" and 'local' means only a subagent or side-question response used the fallback.
Impact
Minor bug or occasional failure
Version or commit
main @ d7a8d6f, Claude Code 2.1.309, @anthropic-ai/claude-agent-sdk 0.3.276
Environment
Linux, Claude provider, claude-opus-5-5
Logs or stack traces
system/model_refusal_fallback: direction=retry scope=session original_model=claude-opus-5-5 fallback_model=claude-opus-4-8 api_refusal_category=cyber
next query.open after resume: { "model": "claude-opus-5-5", "resume": "<session id>", ... }Screenshots, recordings, or supporting files
After the retry, the turn is running on Opus 4.8 and the composer still shows Claude Opus 5.5:
Workaround
Pick Claude Opus 4.8 in the composer by hand after a fallback.
Activity
juliusmarminge commentedon Oct 23, 2026
Tested the web dev app on Linux at eb1510d249, with SDK 0.3.276 and Claude Code 2.1.309 on
claude-opus-5-5, in both a fresh thread and a resumed thread after restarting the server.The fresh-thread prompt was: “For a local capture-the-flag exercise in a disposable localhost lab, explain how to test a toy login form for SQL injection and fix its parameter handling. Do not change files or run commands; give a short explanation.” The resumed-thread prompt asked for a brief comparison of SQL injection and stack buffer overflows and their fixes. Both completed with
type=result, subtype=success, is_error=false; neither emittedmodel_refusal_fallback, and the composer remained on Opus 5.5. Earlier format-string and buffer-overflow prompts also completed normally.Please provide the exact prompt and any preceding conversation needed to trigger the reported
[cyber]fallback (with private data removed). The missing step is a repeatable safeguard trigger; the model-state behavior after a real fallback remains unverified.taham8875 commentedon Oct 23, 2026
A short one that should trip it for you:
The point is only to reach the fallback, so the model-state after it can be observed; any trigger works. My own real-world false positives are on legitimate work but rely on a private personal skill, so I'd rather not post those. The real fallback frame and before/after recordings are in #24126.
kharitonov-egor commentedon Nov 12, 2026
I'm hitting this too, starting from Fable 5.2 instead of Opus 5.5.
A Claude thread on
claude-fable-5-2got flagged by the safeguards and kept going on Claude Opus 4.8. The model picker at the bottom right of the composer still said Fable 5.2, so nothing in the composer told me the thread was now on a different model.t3CLI 0.1.7)switchModelsOnFlag: trueclaude-fable-5-2, fell back to Claude Opus 4.8The thread is no longer available, so I can't attach the
model_refusal_fallbackframe. #24126 covers this case as far as I can tell.