Sub-Agent task_complete Bug: Race Condition Causes Response Loss

[PlaneInABottle]

Sub-Agent task_complete Bug: Race Condition Causes Response Loss

Summary

When sub-agents (spawned via the task tool) are instructed to use the task_complete tool, their responses are not captured by the parent agent, resulting in "General-purpose agent did not produce a response." This is a race condition in the sub-agent framework that affects all Claude models (Opus 4.6, Sonnet 4, Sonnet 4.5, Haiku 4.5), not just Opus 4.6.

Root Cause

The Copilot CLI sub-agent framework extracts responses from the sub-agent's text output stream, not from the task_complete summary. When a sub-agent calls task_complete, it terminates the response stream. This creates a race condition:

Happy path (works):

1. Sub-agent emits text response
2. Sub-agent calls task_complete
3. Parent captures text before stream terminates
4. ✅ Response returned successfully

Bug path (fails):

1. Sub-agent calls task_complete as first/only action
2. Response stream terminates immediately
3. Parent receives empty/null response
4. ❌ "General-purpose agent did not produce a response"

Evidence

Experimental Results

Spawned sub-agents with identical tasks, varying only whether they're told to use task_complete:

Model	With task_complete	Without task_complete
claude-opus-4.6	6/13 success (46%)	2/2 success (100%)
claude-sonnet-4.5	0/1 fail	—
claude-sonnet-4	0/1 fail	1/1 success
claude-haiku-4.5	0/1 fail	—
claude-opus-4.5	1/1 success	—
gpt-5.1	1/1 success	—

Key findings:

1. Bug affects all Claude models as sub-agents, not just Opus 4.6
2. Failure is non-deterministic (46% success rate for Opus 4.6)
3. GPT models appear unaffected
4. Without task_complete instruction: 100% success rate

Non-Deterministic Behavior

Prompt intensity matters:

• Emphatic prompts ("CRITICAL MUST use task_complete ONLY") → 100% failure
• Moderate prompts ("Do X and use task_complete") → ~46% success for Opus 4.6

Why? The more the prompt emphasizes task_complete, the more likely the model calls it before or instead of emitting text, triggering the race condition.

Reproduction

Guaranteed Failure (100%)

task(
    agent_type="general-purpose",
    prompt="""
    Your ONLY job is to call task_complete with summary "Test".
    
    CRITICAL: Use task_complete tool. Do not write any other response.
    """,
    mode="sync",
    model="claude-opus-4.6"
)
# Result: "General-purpose agent did not produce a response"

Non-Deterministic Failure (~54%)

task(
    agent_type="general-purpose",
    prompt="""
    Count files in scripts/ directory.
    
    IMPORTANT: You MUST use task_complete when done.
    """,
    mode="sync",
    model="claude-opus-4.6"
)
# Result: Sometimes works, sometimes "did not produce a response"

Guaranteed Success (100%)

task(
    agent_type="general-purpose",
    prompt="""
    Count files in scripts/ directory.
    
    DO NOT USE task_complete. Return your findings directly.
    """,
    mode="sync",
    model="claude-opus-4.6"
)
# Result: Always returns response

Impact

Affected:

• All Claude model sub-agents (Opus 4.6, Sonnet 4/4.5, Haiku 4.5)
• Both sync and background modes
• Parent agents cannot reliably use Claude sub-agents if prompts mention task_complete

Not affected:

• GPT models (gpt-5.1, gpt-5.2-codex)
• Claude Opus 4.5 (appears more reliable but not tested extensively)
• Direct agent usage (non-sub-agents)

Workaround

For sub-agent prompts: Never instruct sub-agents to use task_complete. The parent framework already handles completion signaling. Instruct them to return findings directly:

task(
    agent_type="general-purpose",
    prompt="""
    Analyze X and report findings.
    
    DO NOT USE task_complete tool. Return your response text directly.
    """,
    mode="sync",
    model="claude-opus-4.6"
)

Success rate: 100% with this workaround

Recommended Fix

The framework should:

1. Buffer text output before allowing task_complete to terminate the stream
2. Ensure response serialization completes before terminating agent context
3. Consider making task_complete a soft signal rather than immediate termination
4. Or: Auto-suppress task_complete for sub-agents since parent framework already tracks completion

The fundamental issue is that task_complete terminates execution before ensuring the response text is captured, creating an avoidable race condition.

Environment

• Copilot CLI version: 0.0.405
• OS: macOS (Darwin)
• Affected models: All Claude models (tested: Opus 4.6, Sonnet 4, Sonnet 4.5, Haiku 4.5)
• Working models: GPT-5.1, GPT-5.2-Codex

Related

This issue was initially reported as Opus 4.6-specific, but debugging revealed it affects all Claude models when used as sub-agents. The non-deterministic nature made it appear model-specific initially.

[PlaneInABottle]

Update: Opus 4.6 also fails in sync mode

New Evidence

Opus 4.6 also fails in sync mode (not just background mode):

Test case:

task(
    agent_type="general-purpose",
    prompt="Brainstorm SQL/todos for all agents",
    mode="sync",  # NOT background
    model="claude-opus-4.6"
)

Result: "No response generated"

Critical Pattern Discovered

User observation: "I feel like it always fails after marking a task complete"

Looking at the agent output traces:

● General-purpose(claude-opus-4.6): Brainstorm SQL/todos for all agents
  ● Explore: Check subagent tool access
    └ Based on my exploration, here are the **concise findings**:
  ● Task complete: Proposed 3 options...
    └ Task marked as complete. Summary: Proposed 3 options...

The agent IS working and producing output, but:

1. Calls task_complete tool at the end
2. Response gets lost/not serialized AFTER task_complete
3. Returns "No response generated" to coordinator

Root Cause Hypothesis (Updated)

Opus 4.6 agents call task_complete which terminates execution BEFORE the response is serialized/returned.

This explains:

• ✅ Why background mode fails (seen earlier)
• ✅ Why sync mode ALSO fails (new finding)
• ✅ Why status shows "completed" (task_complete was called)
• ✅ Why "no response" (response lost after task_complete)
• ✅ Why other models work (they don't have this timing bug)

Impact (Updated)

• Cannot use Opus 4.6 for any general-purpose tasks (background OR sync)
• Must use Opus 4.5, GPT-5.2, or other models as workaround
• Misleading "completed" status when actually failed

Workaround

Use claude-opus-4.5 instead of claude-opus-4.6 for all general-purpose tasks.

[PlaneInABottle]

Workaround Found: Explicitly disable task_complete

Discovery

When Opus 4.6 agents are explicitly instructed NOT to use the task_complete tool, they return responses successfully!

Test case:

task(
    agent_type="general-purpose",
    prompt="""
    **CRITICAL INSTRUCTION: DO NOT USE THE `task_complete` TOOL AT ALL.**
    
    Simply analyze the file and return your findings directly.
    
    Your task: Count lines and list section headers in master.md
    
    **REMEMBER: Do NOT call task_complete. Just return your response text.**
    """,
    mode="sync",
    model="claude-opus-4.6"
)

Result: ✅ Full response returned successfully!

File: templates/global-instructions/master.md
Total lines: 264

Section headers:
- ## Role and Identity (line 3)
- ## Fundamental Principles (line 15)
... (14 headers listed)

Analysis complete.

Root Cause Confirmed

The bug is a race condition:

1. Opus 4.6 calls task_complete(summary="...")
2. The task_complete tool terminates agent execution immediately
3. Agent context/session closes before response text is serialized/captured
4. Orchestration layer receives "completed" status but empty response body

Why other models work:

• They either call task_complete less frequently
• Or their execution timing allows response serialization before termination

Workaround

Include this in the prompt when using Opus 4.6:

DO NOT USE THE task_complete TOOL. Just return your response text directly.

This forces the agent to complete the response turn naturally without premature termination via task_complete.

Implications

• This is a timing/race condition bug in how Opus 4.6 agents interact with task_complete
• The tool itself may be terminating the agent session too aggressively
• Other models likely have different execution timing that avoids the race

Recommended Fix

The task_complete tool should ensure response serialization is complete before terminating the agent context. Possible approaches:

1. Buffer/flush the response before calling task_complete handler
2. Delay context termination until response is confirmed captured
3. Make task_complete a "soft signal" rather than hard termination

[etse1288]

got this error and my flow never finish:

The agent instructions repeatedly request calling task_complete to signal completion, but this tool **does not exist** in the available function set and never has.

[etse1288]

Looks like they fixed the models? Today i tried the same workflow with no CLI version update and it is working (no more "race condition") @PlaneInABottle what about your cases?

[PlaneInABottle]

Yeah now it looks like agent sees task completed return instead of no response, but I am still not convinced this is the right way. Agent doesn't see the rest of the explanation of the subagent. Only task complete is shown to the main caller

Looks like they fixed the models? Today i tried the same workflow with no CLI version update and it is working (no more "race condition") @PlaneInABottle what about your cases?

[etse1288]

my subagents create .json files for the main agent to pass to other subagents, so task completed is probably sufficient for me...

[PlaneInABottle]

I am closing this issue since it is solved, main agent no longer gets no response from subagents

[etse1288]

thanks for reporting this issue with detailed information