[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.

[Datakunskap]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Expected behavior

I can send a prompt or stop these sub-agents somehow to be able too...?

Actual behavior

Locked up. Every message results in this error, and lineage shows all subagents are completed.

Impact

Blocks work completely

Version or commit

main@latest

Environment

macOS Golden Gate (latest)

Logs or stack traces

"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."

Screenshots, recordings, or supporting files

No response

Workaround

Starting a new thread.

[Datakunskap]

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.

[juliusmarminge]

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.

[Datakunskap]

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.

[Datakunskap]

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.