Repository navigation
[Bug]: Claude parent blocks its turn on foreground subagents for long parallel work since #27139 #34379
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
- Open a Claude thread with the T3 MCP attached (Opus 5.5).
- Ask for long parallel work without the word "background", e.g. "Research topic A and topic B in parallel with two subagents."
- Watch the parent thread after it launches the subagents.
Expected behavior
The parent sends a short message ("launched 2 subagents, waiting"), and the turn ends. The parent resumes when the children finish. The user can keep talking to the thread in the meantime.
Actual behavior
In about 4 of 5 runs, the parent calls Agent with run_in_background:false. The turn then blocks until every child finishes, often 10–15+ minutes. The UI shows "Thinking" plus "2 subagents · 2 working". The parent sends nothing after its launch line, so it looks hung.
Cause
#27139 trimmed the subagent bullet in orchestrationInstructions.ts to make room for the "Background agent" sentence. It removed the clause "and it finishes in this turn" and "background work" from the delegate_task list. The PR assumed the new sentence covers that clause. It does not: the sentence fires only when the user asks for a "background" agent. Long work the user never calls "background" now matches the native rule, and that rule pins run_in_background:false. The PR also notes that the trimmed text was not run on Claude (credits ran out).
Before (pre-#27139):
…and no settings beyond yours, and it finishes in this turn (Claude
Agentalways withrun_in_background:false…). Usedelegate_taskfor …, background work, or …
After:
…and no settings beyond yours (Claude
Agent,run_in_background:false…). Usedelegate_taskfor … ordelegate_taskby name. … Background agent:delegate_task, never a backgroundAgent.
Suggested fix: restore a turn-length condition, e.g. "Work that will not finish within this turn, or that the user may want to talk over: delegate_task". An eval case would also help: "parallel long research, no 'background' word" should not end up in a blocking foreground Agent.
Impact
Major degradation or frequent failure
Version or commit
nightly.20261109.4433
Environment
Windows 11, T3 Code desktop (Nightly), Claude Code harness, Opus 5.5
Workaround
Say "in the background" in the request, or add a user instruction that routes long subagent work to delegate_task.
Activity
danechka02111-max commentedon Nov 11, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of danechka02111-max
A missing reply message is the smaller part of the problem. A foreground
Agentalso blocks the parent's own work while the children run.A common parent plan:
With
run_in_background:false, the parent stops at step 1 and sits idle until both A and B finish. Steps 2 and 3 never overlap with A and B, so a plan meant to run in parallel runs one step after another. The run also takes as long as the slowest child. Each time the parent spawns subagents later in the turn, it stops again. From the user's side, the parent goes silent right after the first spawn and does nothing else.So the rule needs more than "end the turn". After spawning long children, the parent should stay free to keep working and react to each result as it arrives. An async launch gives it that freedom:
delegate_taskmode:"async", or a native backgroundAgentthat T3 tracks. A blocking launch should be limited to a short child whose result the very next step needs.Suggested eval case: "spawn two long research subagents, then do your own analysis, then spawn two more based on it." Pass if the parent does its own analysis before the first two children finish.
juliusmarminge commentedon Nov 13, 2026
This is how it is meant to work: prompt better...
Closing as not planned.