TaskOutput hangs after background agent completes

[stream727]

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

1. Start a background agent with Task(..., run_in_background=true)
2. Wait for results with TaskOutput(task_id) (with block=true)
3. Agent completes its work
4. Main session remains stuck in "Waiting for task" / "Booping…" state
5. More than 5 minutes pass without detecting completion
6. Manually cancel with Esc key, 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".

[github-actions]

Found 3 possible duplicate issues:

1. Session freezes indefinitely when multiple background agents + blocking TaskOutput #17540
2. [BUG] Background task queue operations after completion signal cause session hang (stop_reason: null) #19195
3. Bring back rainbow highlighting for "ultrathink" keyword (as cosmetic feature) #18884

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[stream727]

Related issues that may have the same root cause:

• TaskOutput block=true locks out user with no escape #17515
• Session freezes indefinitely when multiple background agents + blocking TaskOutput #17540
• [BUG] Background task queue operations after completion signal cause session hang (stop_reason: null) #19195
• [BUG] Session hangs at 0 tokens after background task completes with --dangerously-skip-permissions #20048
• v2.1.12 regression: UI freezes after work completes or on session resume (message rendering fix broke state recovery) #19569

This appears to be a v2.1.12+ regression affecting TaskOutput/background task completion detection.

[ianbmacdonald]

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.

Its just sitting there waiting for me to tap ESC

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.

...
- Code quality: 297 tests pass (17 slow tests skipped), no lint errors `
...

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).

[ianbmacdonald]

Definately just hanging around

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

Still alive and ready to go, [+9h] like nothing happened