[Bug]: Claude refuses every message as a "model or setting change" when a thread moves between mobile and web while background work runs #15471

Activity

1. vitalyiegorov commented on Oct 4, 2026

   

   vitalyiegorov

   on Oct 4, 2026

   ContributorAuthor

   More actions

   PR opened: #15473. For models that expose fast mode, an unset fastMode now compiles as Normal, which is what the web composer already sends. Mobile and web then produce the same query identity, and the #14726 guard stays as it is.
2. juliusmarminge commented on Oct 4, 2026

   

   juliusmarminge

   on Oct 4, 2026 – with Cursor

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @vitalyiegorov for the run records and the root-cause write-up; they made this quick to confirm. I checked it on 8fb068c498 (the nightly you reported against), and the code matches your table.

   What I found

   • Web and desktop send Normal as an explicit fastMode: false. withImplicitFastModeDefault in apps/web/src/components/chat/composerProviderState.tsx adds that option for every model with a fast-mode descriptor. Mobile only keeps the options that were actually selected, so a Claude thread started there has no fastMode option.
   • compileClaudeModelSelection (apps/server/src/claudeModelOptions.ts) keeps them apart: an omitted value stays out of settings, while false becomes { fastMode: false }. queryIdentity includes that object, so the two sends don't match.
   • openQuery in ClaudeAdapterV2.ts only reuses the live process when the identity matches. While that process has background work and isn't stopping, the mismatch raises ClaudeBackgroundWorkBlocksQueryReplacementError, which is the message you saw. Opus 5.5 exposes fastMode in the bundled catalog, so this model hits it.
   • Server continuations skip the check (isClaudeProviderContinuationTurn), which is why runs 15 and 16 completed with no options.
   • After the shell exits, the next web send still has a different identity, so the process is replaced and resumed. That explains the Opus 5.5 to Opus 5.5 handoff without any real model change.
   • Stop failing afterwards is tracked in [Bug]: Stop can't end background work after a run fails before its provider starts ("Run … is not interruptible") #15472: this refusal fails the run before a provider turn exists, so interrupt rejects that run.

   Likely fix area

   Some options:

   • Normalize an unset fastMode to false in compileClaudeModelSelection for models that expose fast mode, so omitted and explicit Normal produce the same identity. A real switch to Fast would still change the identity, so the fix(server): Claude model changes no longer kill running background agents #14726 guard would keep blocking it while background work runs. That's the approach in your open PR fix(claude): a thread with background work no longer refuses messages sent from another client #15473.
   • Alternatively, normalize on the clients so mobile and web send the same option set, though a server-side fix would also cover older clients and continuations.

   A maintainer will decide on the fix direction.
3. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 4, 2026
4. CoreInfusion commented on Oct 4, 2026

   

   CoreInfusion

   on Oct 4, 2026

   More actions

   Same failure through a second path, with no mobile client involved. This one is likely common with orchestration v2:

   1. A thread is created by an agent through the MCP tool t3_thread_launch with modelSelection: {instanceId, model} and no options. Later turns come from an outside client through orchestration.dispatchCommand / message.dispatch without modelSelection. The live Claude query therefore runs with settings: {} in its queryIdentity.
   2. The agent starts a background task (a Monitor waiting on a build).
   3. The user then types in the web client. That message carries options: [{id: "fastMode", value: false}], giving settings: {fastMode: false}, a different selectionKey. openQuery treats it as a model/setting change and throws ClaudeBackgroundWorkBlocksQueryReplacementError. Three messages in a row were refused; nothing had changed.

   Cause as seen in the bundle: compileClaudeModelSelection adds fastMode to settings only when the option is present, so an explicit default value and a missing option produce different queryIdentity strings. Normalizing defaults before building the identity would cover both the mobile/web case in this issue and the MCP/outside-client case.

   Version: 0.0.46-nightly.20261003.2632 (Linux server), claudeAgent / claude-opus-5-5. The thread then broke for good the way #15103 describes (details there).
5. maria-rcks

   closed this as completedin #15770on Oct 4, 2026