[Bug]: Claude is still running background agents or commands, and this model or setting change would end them. Wait for them to finish, or press Stop, then send the message again. #16073

Activity

1. Datakunskap

   added

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

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
2. Datakunskap commented on Oct 5, 2026

   

   Datakunskap

   on Oct 5, 2026

   Last edited by Datakunskap

   Author

   More actions

   After waiting for ages it seemed to let me compact but now results in this error... Looks like my most important thread is scrapped 😿

   

   In case it's helpful, I first did several steer messages, which seemed to work, but now new prompts do not give me a steer option. Instead, it just goes queued and gives this error.
3. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the screenshot and the lineage note, @Datakunskap. This matches the Claude guard added in #14726.

   What I found

   • A new user turn that would close the live Claude process is refused while that process still has background work. The text in your screenshot is ClaudeBackgroundWorkBlocksQueryReplacementError from openQuery in apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts.
   • The screenshot shows that split. Rows titled "Background activity updated" still ran after the health-check reply. Those are continuation wakes, and they keep the live process (isClaudeProviderContinuationTurn), so they never hit this check. The messages you sent do. "Also bypass Astra review as that will take too long…" is marked Queued and then fails at 8:58 with this error. "Updates?" fails the same way at 9:01. The composer under that is idle ("Ask anything"), on Claude Opus 5.5, Extra High, 1M context, Full access. There is no Stop on that composer.
   • Steer worked earlier because steer never replaces the process. While a turn is running, Steer offers into the live query (steerTurn). The default follow-up is Queue, so a normal send is marked Queued and starts a new turn. openQuery reuses the process only when both the model identity and the query policy match. Extra High, the 1M suffix, fast mode, and Full access are all part of that. Any difference is treated as a model or setting change and refused, instead of killing the background work. Once the turn is no longer running, the composer has no Steer action, which matches what you described.
   • Completed subagents in lineage do not clear this. The guard also counts the background roster (shells and monitors), not only subagent cards. "Background activity updated" is that other work waking the thread. The error's "press Stop" is the background-work strip above the composer (Running / Waiting … Stop), which is only shown when the turn itself is not working. Stop closes the live process so the next send can open a new one. A new thread also drops that process, which is why that workaround gets you unstuck.
   • One form of this already shipped. [Bug]: Claude refuses every message as a "model or setting change" when a thread moves between mobile and web while background work runs #15471 and [Bug]: Stop can't end background work after a run fails before its provider starts ("Run … is not interruptible") #15472 were an omitted fastMode versus an explicit Normal (fastMode: false) looking like a setting change, and Stop on the failed run returning "not interruptible". That is fix(server): Claude threads no longer get stuck after background commands #15770, in nightly v0.0.46-nightly.20261004.2657 and in today's v0.0.46-nightly.20261005.2676. "main@latest" does not say whether the desktop app is on that build. If this is from before that nightly, updating should clear this stuck state. If you are on 2676 or later, this is still open: user turns keep failing after those wakes, and the idle composer has no Stop.

   Likely fix area

   • If the stuck state still happens on 2676 or later: clear or expose Stop when the live process still has background roster work after the turn goes idle, and/or avoid treating a policy identity mismatch as a blocked replacement when the user has no other way to stop that process from the idle composer.
   • Related open reports in the same area: [Bug]: Stale "Waiting on background task T3 Worktree Handoff" banner persists after a Claude worktree handoff #15993 (stale waiting banner), [Bug]: Runtime-mode, instance and worktree changes detach the Claude session and kill live subagents without the background-work check #16000 (opposite: detach kills without guard), Claude thread permanently fails with "No conversation found with session ID" after fresh-session fallback resumes a newly minted id #15103 (session id after background).

   A few details would help pin which case this is:

   • The version string from the desktop app, or the nightly tag, not just main@latest.
   • Whether a strip above the composer says Running or Waiting and has Stop, and the exact toast if you press it.
   • Whether Opus 5.5 / Extra High / 1M / Full access was the selection for the whole thread, or changed after the background work started.

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

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
5. Datakunskap commented on Oct 5, 2026

   

   Datakunskap

   on Oct 5, 2026

   Author

   More actions

   Thanks for the detailed triage. Here are the details you asked for, plus a second error that came after this one.

   Version: 0.0.46-nightly.20261005.2676, the latest nightly (published 2026-10-05 11:02 UTC; nothing newer is released). The server trace shows 2676 running from about 07:48 EDT, so the whole incident (08:58–09:28 EDT) was on it. That makes it the still-open case, not the one fixed in #15770.

   Background work that blocked the replacement: the agent had started two Monitor tasks during a deploy, at 08:51:49 and 08:52:56 EDT. Both ran tail -f <log> | grep … with a 30-minute timeout. tail -f never exits, so they stayed in the background roster after the deploy finished at 08:57. Their output files end with [killed], written at 09:09, when a continuation wake ("Command … finished") ran. No subagents were running.

   Strip / Stop: no Running or Waiting strip was shown above the composer. The composer was idle ("Ask anything") with only the send button, so I had no way to stop that background work.

   Selection:

   • Opus 5.5 / Extra High / 1M / Full access was the thread's selection the whole time. The Claude processes were launched with --effort xhigh --model claude-opus-5-5[1m].
   • The two refused messages (08:58 "Also bypass Astra…" and 09:01 "Updates?") were sent from the mobile client.
   • Thread configuration read through MCP at about 09:17 EDT: effort: xhigh, contextWindow: 1m, with no fastMode key. After my next send from desktop/web at 09:21, it read effort: xhigh, fastMode: false, contextWindow: 1m.
   • So the omitted vs explicit fastMode difference ([Bug]: Claude refuses every message as a "model or setting change" when a thread moves between mobile and web while background work runs #15471/[Bug]: Stop can't end background work after a run fails before its provider starts ("Run … is not interruptible") #15472) may still be what got treated as a setting change on 2676, at least for mobile sends.

   Second error after the background work cleared: at 09:21 EDT the send was refused with a different error:

   Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.

   That is ContextHandoffBudgetError from deliverContextHandoffs. My reading of the code: the handoff carried a delta_since_target_last_seen retry of the failed runs' items (88/89), and handoffBudget got ≤ 0. It appears to have used the session's last reported usedTokens, which was near full after about 3 days and 1,540 items, even though the native session behind it was effectively empty.

   Evidence: sending /compact (which uses deferInline and skips the budget check) returned "Error: No messages to compact" at 09:28. The very next message went through normally.

   So it looks like:

   1. the replacement guard fired with no Stop available;
   2. the native session was replaced once the monitors were killed;
   3. the handoff budget was still computed from the old session's usage, so every send failed until /compact refreshed the usage figure.

   Workaround for anyone who hits it: send /compact, then resend.

   Happy to share trace excerpts or run IDs if useful.
6. Datakunskap commented on Oct 5, 2026

   

   Datakunskap

   on Oct 5, 2026

   Author

   More actions

   Follow-up, same day and still on 0.0.46-nightly.20261005.2676: it happened again this evening. The provider log also shows that twice today the "replacement" opened a brand-new Claude session instead of resuming, which wiped the agent's working context.

   Timeline from ~/.t3/userdata/logs/provider/events.<threadId>.log (query.open / query.close, EDT):

   Time	Event	Native session	fastMode
   07:39:57	open	resume 62be6cd5	false
   09:09:24	close, then open	new sessionId f49c29ab (no resume)	false
   10:10:58	close, then open	resume f49c29ab	true
   15:46:35	open (scheduled-task run)	resume f49c29ab	true
   16:49:40	close, then open (a different scheduled task)	resume f49c29ab	false
   17:50	scheduled-task run fails after 0.1 s: ClaudeBackgroundWorkBlocksQueryReplacementError	—	—
   17:56	thread selection set to fastMode: false via t3_thread_configure; the task re-run via run_scheduled_task_now fails the same way	—	—
   18:13:21	background command finishes, continuation turn completes, then close and open	new sessionId 04c261d2 (no resume)	true
   19:24:02	close, then open	resume 04c261d2	false

   Notes on the rows:

   • 09:09:24: right after the continuation wake that followed the killed tail -f monitors. This is why /compact later said "No messages to compact".
   • 10:10:58: 31 s after a message I sent from the mobile app. I never knowingly turned fast mode on, so the mobile composer seems to carry it.
   • 17:50: a run_in_background Bash command (about 30 minutes, started at 17:41) was running.

   What this shows

   1. fastMode flips depending on who starts the turn.
      • Mobile sends seem to carry fastMode: true.
      • Two scheduled tasks carried different values, which fits each task capturing the selection when it was created.
      • Every flip forces a query replacement. A scheduled turn that arrives while background work is running fails instead of waiting.
      • At 17:56, changing the thread's selection did not rescue the re-run of the scheduled task.
   2. Two replacements opened a fresh sessionId instead of resume (09:09 and 18:13). Both came right after a continuation wake for background work that had just finished or been killed, so this may be related to Claude thread permanently fails with "No conversation found with session ID" after fresh-session fallback resumes a newly minted id #15103.
      • This is the most damaging part: the model starts with an empty conversation and only gets the bounded handoff. The full thread history is still in T3.
      • Today that hit a long-running thread that was in the middle of multi-step operational work.
   3. This time the mobile app did show the strip above the composer, "Running: Run kit qualification…", with Stop. Pressing Stop would have killed a 30-minute job, so it wasn't a real option.

   Suggestions (your call)

   • If a queued or scheduled turn is blocked only by background work, keep it queued and start it when the work finishes, instead of failing it.
   • Don't let a fastMode-only difference between clients or scheduled tasks force a process replacement. Alternatively, have scheduled tasks use the thread's current selection.
   • When a replacement is unavoidable, always resume the existing native session.

   I can share log excerpts or run IDs if useful.
7. GoblinRules commented on Oct 8, 2026

   

   GoblinRules

   on Oct 8, 2026

   More actions

   Same message hit on Windows, 0.0.46-nightly.20261007.2774, claudeAgent / claude-opus-5-5, while an Explore subagent was running. Two model-change sends were refused (09:03, 09:04 UTC). At 09:06 T3 closed the query and opened a fresh session bb2c228c… with no resume. That session was never persisted, and every later turn failed with "No conversation found with session ID", so the thread is permanently bricked (the #15103 / #15866 path).

   Suggestion: instead of rejecting a model or setting change while background work runs, queue it. Show "Will switch to X when background tasks finish", with Switch now (stops them) and Cancel buttons, and apply it automatically when the last task settles. Rejecting the send loses the user's message and invites retries, which is how this thread ended up broken.
8. caitlon commented on Oct 11, 2026

   

   caitlon

   on Oct 11, 2026

   More actions

   Another case for the wording, on t3 v0.0.45 (claudeAgent, Opus 5.5). The thread was launched by another agent through t3_thread_launch with effort high, and its process runs with --effort high, but the composer's selector showed Max. I had not consciously changed anything, so the error ("this model or setting change would end them") gave no hint what the change was or how to undo it. Switching the selector back to High let the message through without a restart.

   Two small changes would have made this self-explanatory, alongside the queueing idea above:

   • name the difference in the error, e.g. "This thread runs Opus 5.5 at High; the selector is set to Max. Sending with Max would restart Claude and stop 5 background agents.";
   • offer Send with High (the running setting) as a one-click action next to Stop.

   It may also be worth checking why a launched thread's selector shows a different effort than the one it was started with.
9. juliusmarminge commented on Oct 14, 2026

   

   juliusmarminge

   on Oct 14, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Closing this as fixed by #19341, which just merged. Changes to model, effort, Ultracode, or Fast mode are now applied to the running Claude process, so they no longer get refused while background agents or commands are running. That covers the effort, model, and fastMode flips reported here.

   Two refusals stay by design because they need a new process: turning thinking on or off, and switching to a model without effort (such as Haiku 4.5). The parts that are still open are tracked separately: the "Insufficient context allowance" failure after a refused turn is #17952, and replacements that open a new session without resume are #15103. If you still hit this error on a build that includes #19341 for any other change, please open a new issue with the version.
10. juliusmarminge

    closed this as completedon Oct 14, 2026