Background task completion notifications silently lost for async subagents (3x in one session, intermittent, recurring)

Status Open
Reported on v2.1.241
Maintainer reply None cached
Activity 0 comments · opened Aug 25, 2026

Environment: Claude Code 2.1.241 (CLI), macOS Darwin 25.5.0, model claude-fable-5.

Setup: the main session spawns an async general-purpose subagent via the Agent tool. The subagent launches long shell jobs via Bash run_in_background (or foreground commands auto-backgrounded at the ~590s timeout) and ends its turn to await the background-task completion notification.

Bug: the background job completes normally (process exits; in our pattern the job's final act writes a DONE marker file) but the completion notification is never delivered. The subagent stays parked indefinitely — it only resumes when the parent session manually sends it a message.

Three instances in a single subagent run on 2026-08-24 (local time; all verified by the parent session checking the marker/log mtimes and ps before manually waking the agent):

  1. A long verification script that was auto-backgrounded after exceeding the 590s foreground timeout. Script finished 19:01 (log complete, zero matching processes); no wake had arrived 9+ minutes later.
  2. A fetch loop launched with run_in_background, plus a second run_in_background watcher (until [ -f marker ]; do sleep 30; done) armed specifically as an independent wake path. The job completed and wrote its marker at 21:20; neither the job's completion notification nor the watcher's arrived by 21:35.
  3. A cargo test --release run in background with the same marker pattern; completed 21:48; no wake by 22:09.

Instance 2 is the strongest signal: two independent background tasks completed and neither notification delivered, suggesting the loss is in the notification-delivery path for that agent rather than per-task.

Intermittency: other background completions in the same subagent session delivered fine (several earlier jobs woke it normally), so delivery is intermittent, not uniformly broken.

History: the same symptom cluster appeared 2026-08-13/14 (5+ silent failures across sessions) after roughly four weeks of reliable behavior, then recurred 2026-08-24 as above.

Impact: unattended multi-hour orchestration stalls silently; silence is indistinguishable from "still running." Current workaround: an external watchdog in the parent session monitoring a progress file's mtime, plus manual resume messages to the parked agent.

View original on GitHub ↗