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