[Bug] (with repro) TaskOutput tool incorrectly hidden from subagents
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 6 comments · opened Dec 22, 2025 · closed Feb 1, 2026
Bug Description
The TaskOutput tool appears to be incorrectly hidden from subagents.
Here's a kinda minimal repro, after I asked claude to "Launch a subagent to do something slow and long running, in the background. Then launch a subagent to try to consume the output of the background subagent by using TaskOutput.":
---
Let me launch a background subagent that does something slow, then launch a second subagent to consume its output:
⏺ Task(Slow background task)
⎿ Backgrounded agent
⎿ Prompt:
Do something that takes a little while - search for all Swift files in this repository and count how many contain "@Observable", then count how many contain "ObservableObject". Report both counts and which pattern is more
prevalent. Take your time and be thorough.
∴ Thinking…
Good, the first subagent is now running in the background. Now I need to launch a second subagent that will use TaskOutput to consume the output of the first subagent. I'll pass the agent ID to the second subagent so it can use
TaskOutput to get the results.
⏺ Background agent launched (ID: a29602e). Now launching a second subagent to consume its output: 06:19 PM claude-opus-4-5-20251101
⏺ Task(Consume background task output)
⎿ Prompt:
There is a background subagent running with ID "a29602e" that is counting @Observable vs ObservableObject usage in Swift files.
Your task is to:
1. Use the TaskOutput tool to wait for and retrieve the results from that background agent (use task_id: "a29602e", block: true)
2. Once you have the results, analyze them and provide a brief summary
3. Add your own observation about what this pattern prevalence might indicate about the codebase's modernity
This tests the subagent-to-subagent communication pattern via TaskOutput.
> There is a background subagent running with ID "a29602e" that is counting @Observable vs ObservableObject usage in Swift files.
Waiting…ude task-output a29602e --block)
Error: Exit code 1
Waiting…ude task-output a29602e)
It looks like you're asking me to retrieve output from a task, but I don't have a specific task ID to check. This appears to be the start of a new session.
Waiting…ude tasks)
I'll analyze the user's request and evaluate the relevant skills and agents.
⎿ Interrupted · What should Claude do instead?
⏺ Agent "Slow background task" completed.
⎿ Interrupted · What should Claude do instead?
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.0.75
- Feedback ID: cf6e2445-e2ac-4821-8a46-2a974897951b
Errors
[{"error":"Error: Request was aborted.\n at OT.makeRequest (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:857:3940)\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)","timestamp":"2025-12-22T23:21:42.916Z"},{"error":"Error: Request was aborted.\n at d71 (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:1346:19457)\n at d71.next (<anonymous>)\n at PW9 (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:4593:1426)\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n at async file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:4591:3799\n at async d00 (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:1007:2037)\n at async zHA (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:4591:3769)\n at async ew (file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2207:3569)\n at async file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2709:1990\n at async file:///Users/alexanderriccio/.nvm/versions/node/v24.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2709:2831","timestamp":"2025-12-22T23:21:43.313Z"}]
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
After hacking together a workaround, I had claude generate this as documentation for others, and potentially for anthropic employees (if they aren't aware of the problem):
Comprehensive Workaround: Reading Subagent Outputs via File System
We've been heavily invested in using Claude Code for complex orchestration workflows where a main agent launches multiple background subagents, then needs to consolidate their outputs. The
TaskOutputbug described in this issue was blocking our entire parallel subagent consolidation pattern. After significant investigation, we discovered a working workaround that enables subagent chaining withoutTaskOutput.The Bug (Confirmed)
The
TaskOutputtool appears in subagent tool inventories and documentation but is not actually available when a subagent tries to invoke it. Subagents attempting to useTaskOutput(task_id: "...", block: true)receive errors or the tool simply doesn't function.This prevents the highly valuable pattern of:
TaskOutputto read their responsesThe Workaround: Direct File System Access
Background agents write their outputs to predictable file paths that can be read directly using the
Readtool:Path Construction Algorithm:
/Users/alexanderriccio/Documents/GitHub/MyProject)/characters with-and prefix with--Users-alexanderriccio-Documents-GitHub-MyProject/tmp/claude/{transformed-cwd}/tasks/{agentId}.outputConcrete Example:
/Users/alexanderriccio/Documents/GitHub/DeeDee-Prototypeae1c01c4-8b2a-4f1e-9d3c-5e6f7a8b9c0d/tmp/claude/-Users-alexanderriccio-Documents-GitHub-DeeDee-Prototype/tasks/ae1c01c4-8b2a-4f1e-9d3c-5e6f7a8b9c0d.outputOutput File Format
The output file contains two sections separated by
--- RESULT ---:Parsing Pattern:
Readtool--- RESULT ---Error Handling Matrix
| File State | Meaning | Recommended Action |
|------------|---------|-------------------|
| File doesn't exist | Agent still running or failed to start | Note as "pending/failed", retry later |
| File exists, no
--- RESULT ---| Agent crashed during execution | Flag as crashed, continue with others ||
--- RESULT ---present, empty after | Agent returned empty response | Flag as "no output", continue ||
--- RESULT ---present, content after | Normal successful completion | Parse and use content |Implementation Pattern for Orchestrators
The orchestrating agent must provide
WORKING_DIRECTORYto any consolidation subagent, since subagents need it to construct the file paths:What This Enables
With this workaround, we can now achieve:
Files We've Updated
We've implemented this workaround across our orchestration infrastructure:
subagent-response-consolidatoragent type/orchestrate,/commit-push-review,/auto-task-picker,/prime-flock)CLAUDE.mdcheckpoint gatesRequest
TaskOutputactually work in subagents as documented/tmp/claude/-{cwd-dashed}/tasks/{agentId}.output) is considered stable, documenting it officially would give us confidence to rely on itThe workaround is functional but feels fragile since we're relying on undocumented file system behavior that could change. Any clarity on the intended design here would be appreciated.
---
Happy to provide more details or test any fixes. This is a high-value use case for complex agentic workflows.
Odd, it seems subagents can now use TaskOutput or something similar, BUT something changed in 2.1.0 that seems to sometimes break the workflow by drastically increasing the size of the output, see:
This still seems to be an issue.
I fully stopped using the output of tasks and switched entirely to foreground subagents that write to files.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.