TaskOutput hangs after background agent completes
Status Fixed / completed
Reported on v2.1.17
Maintainer reply ✓ Yes — bcherny
Workaround ✓ Mentioned in thread ↓
Activity 7 comments · opened Jan 23, 2026 · closed Mar 22, 2026
💡 Likely answer: A maintainer (bcherny, collaborator)
responded on this thread — see the highlighted reply below.
Problem Summary
When using TaskOutput to wait for a background task completion, the main session hangs and does not respond even after the agent has completed.
Steps to Reproduce
- Start a background agent with
Task(..., run_in_background=true) - Wait for results with
TaskOutput(task_id)(withblock=true) - Agent completes its work
- Main session remains stuck in "Waiting for task" / "Booping…" state
- More than 5 minutes pass without detecting completion
- Manually cancel with
Esckey, then the completed task's results are displayed
Expected Behavior
- TaskOutput should immediately return results when the agent completes
- Completion detection should work correctly
Actual Behavior
- TaskOutput continues to block after agent completion
- Session hangs in "Booping…" state for several minutes
- Results are only retrievable via manual cancellation (
Esc)
Environment
- Claude Code version: 2.1.17
- Platform: Linux (WSL2)
- OS: Linux 6.6.87.2-microsoft-standard-WSL2
Additional Context
This issue significantly impacts workflows that rely on background agent orchestration. The workaround of manually canceling and re-requesting results is disruptive to automated pipelines.
Possible Root Cause
The completion polling/notification mechanism may not be correctly detecting when the background task state changes from "running" to "completed".
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Related issues that may have the same root cause:
This appears to be a v2.1.12+ regression affecting TaskOutput/background task completion detection.
Claude Code version: 2.1.17
Platform: Linux (Ubuntu 25.10)
Kernel: 6.17.0-8-generic
I noticed today after moving from 2.1.14 yesterday to 2.1.17 I now seem to end up with my session not hung, but pretending it is still doing work, with the clock ticking .. but it is done and no tokens are moving. Like the op here, I just hit ESC and keep on trucking... but it has caught me thinking some background task has not finished a few times today.
<img width="1173" height="420" alt="Image" src="https://github.com/user-attachments/assets/c0bd19fa-17dc-4e8f-89f4-2b6a68f52fc5" />
Its just sitting there waiting for me to tap ESC
<img width="1173" height="420" alt="Image" src="https://github.com/user-attachments/assets/390e6d1e-3ee3-4dfe-977e-1f7bfa12a615" />
In my case, also like the op, evidence of background tests.. some 200+ unit test on this skill, so I wasn't really watching closely
● The output file is empty because it's piped through tail -50. Let me run a fresh test since the earlier command was running tests in the background:
In the end, everything appears wrapped up, looking at the output (excerpt below) and final ouput
Ready to commit, but Claude is still appearing to be working.The workaround, my new skill -> I have learned that it stays in that deep red colour (shown in my screenshots) in this state, rather than getting lighter and darker constantly, which is usually how I first recognize that the bug may have triggered, then if no tokens move for a few minutes, and its not visibly waiting on the last task, I assume I can probably hit ESC and continue (without actually interrupting anything).
Definately just hanging around
<img width="1173" height="420" alt="Image" src="https://github.com/user-attachments/assets/47e7945a-f42c-452e-ae80-901906a4beb9" />
After 9 hours of fake work it looks like it will do this forever; None of the usual watchdog/timeout logic is going to catch this; I Tap ESC and tell it to check out the empty 9 hour gap, and it knows nothing about it and has no context of the idle time apparently
<img width="1173" height="420" alt="Image" src="https://github.com/user-attachments/assets/5dc0fd55-0695-40af-8a2c-6a30a051f2b2" />
Still alive and ready to go, [+9h] like nothing happened
<img width="1173" height="368" alt="Image" src="https://github.com/user-attachments/assets/2cf5d5df-95d2-441c-9d93-264652cd7847" />
This TaskOutput hang is a nasty bug for background agent workflows. The fact that you have to manually cancel and re-request results breaks automated pipelines completely.
The Core Issue
Background agents need:
Current implementation has #1 but fails on #2 and #3.
Workaround Approach
While waiting for Anthropic to fix this, we built ForkOff to solve the orchestration/monitoring problem differently:
How It Helps Background Agent Workflows
Instead of polling for TaskOutput, use push notifications:
No polling. No hangs. Orchestrator knows immediately when agents complete.
Architecture
Specific to This Bug
For the "hanging TaskOutput" case:
Not a perfect fix (Anthropic needs to fix TaskOutput), but keeps your pipeline from being dead-stuck.
Beta Access
Just launched: https://forkoff.app (TestFlight)
Long-term Solution
Anthropic should:
But until then, external orchestration helps.
---
Disclosure: I work on ForkOff. Built this after hitting similar agent orchestration issues.
Fix incoming in the next release.
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.