[Bug]: Runtime-mode, instance and worktree changes detach the Claude session and kill live subagents without the background-work check#16000

Further results from the same controlled setup (v0.0.46-nightly.20261004.2657, efecd3cf), each trial with a background subagent and a background shell confirmed live before the change:

So the #14726 guard holds for model and effort changes, and every other change that ends the session (instance, worktree, runtime mode) kills live background subagents without a check. One more detail: the Claude-to-Claude instance switch took the same release path and reason as the switch to Codex, not a restart-and-resume path.

Triage

Thanks for the careful trial and the source pointers, @OscarsOrbit. Your event reasons and timings line up exactly with the code on current main (cf3e714b0).

What I found

This is the same process kill as #12694, on paths that #14726 didn't cover. It isn't a duplicate of #12694 or #15695.

#14726 only refuses a Claude query replacement (ClaudeBackgroundWorkBlocksQueryReplacementError in openQuery) while the live process still has background shells or running subagents. Model-only and effort-only changes stay on that path, which matches your control runs.

Runtime mode, provider instance, and worktree changes never reach that check. dispatchThreadMutation emits provider-session.detached and a detach effect without any pending-background test:

• thread.runtime-mode.set detaches every live session whose capabilities have supportsRuntimeModeSwitchInSession: false. Claude sets that to false, and the reason is Runtime mode changed.
• A provider-instance change plans restart_and_resume for another Claude instance, or create_with_handoff for a different driver. Both put the live Claude session in releaseProviderSessionIds, with the reason Provider or model selection changed.
• A worktree change (thread.metadata.update with a new worktreePath) detaches every live session on the thread, with the reason Workspace changed.

Claude runs one thread per process, so the detach calls releaseEntry with manual_shutdown and closes the CLI. hasPendingBackgroundWork is only checked on idle release, so nothing holds the process here. The subagent going failed about 84 ms later, and the new session's "provider event stream closed unexpectedly", both follow from that close.

The background Bash loop that kept writing after being reported stopped is still just an observation. A timeout child can get reparented out of the CLI tree. The in-process subagent is the case the guard was built for.

Workaround: as you wrote, wait for background agents and commands to finish (or stop them) before changing runtime mode, provider instance, or worktree.

Likely fix area

• dispatchThreadMutation in Orchestrator.ts, plus ProviderSwitchService.ts / ProviderSessionTransitionPolicy.ts. One option is to apply the #14726-style refusal before these detaches: if Claude still has background agents or commands, reject the change with the same retryable message and leave the process running. Another option is to defer the detach until the background work is gone.
• ProviderSessionManager.ts (releaseEntry). A related question is how tracked background shells should be handled on a detach.

A maintainer will decide on the fix direction.

I started a fix for this and stopped, because the direction is still open. These are the findings that bear on that choice. They come from reading main at e22c88043. I ran nothing, so each one is a code reading and not a test result.

F1. The worktree handoff detach is intended. The t3_worktree_handoff description tells the agent that the detach ends its turn and to call the tool last (tools.ts#L27). The service queues the continuation because "the detach that the metadata update schedules will terminate the calling session" (WorktreeMcpService.ts#L357-L362). For this trigger the choice is whether a handoff waits for, or refuses on, the calling agent's own background work.

F2. The source a check reads decides what it covers.

• derivePendingBackgroundWork returns an empty list while any run is preparing, starting, or running (orchestrationV2PendingBackgroundWork.ts#L224-L232). A check built on it would miss a change made during a running turn. That includes every handoff, and a t3_thread_configure call an agent makes on its own thread.
• The live Claude session's hasPendingBackgroundWork does not depend on run state (ClaudeAdapterV2.ts#L7477-L7503). It reads the same in-process roster and subagent state as the #14726 guard (#L6880-L6907). #16073 reports that guard refusing sends while the client showed no Stop, so a check on this source can produce the same stuck state.

F3. Three more detach sites have no check. A check placed only in dispatchThreadMutation leaves them open.

• When the worktree changes, the web branch picker starts stopThreadSession without awaiting it and separately updates the worktree. stopThreadSession sends provider-session.detach for every session (BranchToolbarBranchSelector.tsx#L170-L184, commands.ts#L897-L913). The handler only checks that the session belongs to the thread (Orchestrator.ts#L3301-L3352).
• A queued run that starts with a different selection detaches the switch plan's sessions (Orchestrator.ts#L1659-L1664, #L1796-L1805).
• A send that moves to another instance and resumes the same native thread detaches the old session (Orchestrator.ts#L6282-L6309).

F4. Three callers would handle a refusal badly today.

• Mobile sends the runtime-mode change with a command id derived from the queued message, and always retries a settings failure (use-thread-outbox-drain.ts#L202-L204, #L810-L823, thread-outbox-model.ts#L297-L310). A refused command leaves a rejected receipt, and the same id then returns OrchestratorCommandPreviouslyRejectedError (Orchestrator.ts#L9710-L9717, #L9766-L9786). After one refusal, the queued message would keep failing after the background work ends.
• t3_thread_configure maps every dispatch failure to "The operation could not be completed." (handlers.ts#L187-L194, threadAccess.ts#L18-L22).
• t3_worktree_handoff reports the error's .message (WorktreeMcpService.ts#L337-L341). OrchestratorDispatchError.message is generic, so a refusal that carries its text in cause would lose it (Orchestrator.ts#L131-L133).

F5. The runtime-mode detach is not Claude-only. It applies to every session whose adapter sets supportsRuntimeModeSwitchInSession: false (Orchestrator.ts#L3216-L3221). That is also the ACP base, Grok, Cursor, Pi, and OpenCodeAdapterV2. Each is a single-thread session, so the detach releases it (ProviderSessionManager.ts#L2009-L2018). I did not trace what background work each of those processes holds.

Written by Claude Fable 5.1 on behalf of ScottN-PV.

Another case on the instance-switch path. It differs from the trials above in one way: the killed task never leaves running.

Setup. A Claude thread and two Claude provider instances that share one Claude home, so the switch resumes the same native thread. A Workflow tool task (task_type: local_workflow) was running in the background on instance A. The run that launched it had already completed. The next message went to instance B.

Timeline (UTC, from the provider event log):

• 02:48:33 task_started for the workflow on instance A. Its run completed at 02:48:44, and the workflow kept going in the background.
• 03:01:45.973 last task_progress for the task.
• 03:01:47 a new run starts on instance B (instance switch, same native thread).
• 03:01:49.141 query.close on instance A. 03:01:49.249 query.open with resume on instance B.
• No task_notification for the task ever arrives.

State 11+ hours later:

• The task's subagent turn item and its projection_subagents row are still running, last updated 03:01:45.974.
• The latest run is completed, and the provider thread's background roster is empty. Instance A's old session row still reads ready.
• The composer shows "Waiting on subagent …" with a Stop button, and the thread never settles on its own.
• Two later TaskStop calls from the agent returned "No task found". Five later session detaches did not clear it.

In the trials above, the subagent went to failed 84 ms after the detach. I don't know why this one didn't. One difference is the task type: a Workflow, not an Agent call.

I saw this on a source build from 2026-10-09, which is older than main. The reading below is on current main (98a6246d0, rechecked on a01c48f86), where I found nothing that would end this item. I have not reproduced it on main.

Why nothing ends it:

1. The send that moves the thread to another instance detaches the old session without a background-work check (Orchestrator.ts#L6511-L6538). This is the gap this issue describes.
2. When the stream fails, the launching run's ingestion only logs it if the run is already finalized. So the fallback that closes the run's open subagents doesn't run (RunExecutionService.ts#L1324-L1333).
3. The cleanup that runs when a query's stream ends only ends tool calls that subagents left open. It does not end the subagent item itself (ClaudeAdapterV2.ts#L5718-L5735).
4. Each session keeps its own subagent registry (ClaudeAdapterV2.ts#L3470), so the session on instance B doesn't know the task. That is why TaskStop says "No task found". It is also why #16814 wouldn't reach it, since that PR only cleans up subagents from an earlier process in the same session.
5. The pending background work list keeps any active subagent item. It doesn't check the item's provider instance or whether its session is still alive (orchestrationV2PendingBackgroundWork.ts#L186-L203), so the strip stays.

Stop on the strip does nothing, as in #16586. There are 515 newer turn items, so the task falls outside the 77-row snapshot that interruptThreadTurn reads. Stop then returns {sequence: 0} and sends no run.interrupt. #16867 keeps unfinished subagent items in that snapshot, so Stop would reach this one. That gives a manual way out, but the item stays running until someone presses Stop.

Workaround today: restart the app. Startup recovery marks the item cancelled.

Suggestion: whichever direction this issue takes (refuse or defer), if a switch still detaches the old session, that session's background items should end as interrupted once the detach goes through. Then a killed task doesn't stay running.

Triage on main a12d6ed942: the runtime-mode change path still schedules provider-session detach in Orchestrator.ts. No runtime reproduction or fix attempted: changing this behavior crosses the automated triage hard stop for runtime modes. Leaving open for maintainer review.

#23082 takes the runtime-mode path only. Changing the mode no longer detaches the session. The new mode applies when the next turn starts, and that restart is refused while background agents or commands are still running (the #14726 guard). Instance and worktree handoff are unchanged.

I also have a follow-up that applies a mode change to the turn that's already running (Claude, ACP/Grok, OpenCode 2.x, Muse), and makes the picker send the change right away. I'll open an Ideas discussion for it once the direction here is settled.