[BUG] run_in_background=true Task agents never deliver report; foreground identical task succeeds (same session A/B)

What's Wrong?

Task agents spawned with run_in_background: true signal idle_notification with
idleReason: "available" but never deliver their final report. The work output is lost
entirely.

I ran a controlled A/B in a single session. Same model, same agent type
(general-purpose), no model override, no isolation. Only run_in_background differs:

| # | run_in_background | Task | Result |
|---|-------------------|---------------------------------------------------|----------------------------|
| 1 | false | Trivial: 2 shell commands, return 3 lines | OK, returned in ~10s |
| 2 | true | Read-only sweep: grep a docs tree, return a table | FAILED, 2x idle, no report |
| 3 | false | Substantive: edit 3 files, 26 tool uses | OK, complete and correct |
| 4 | false | Research: 7 web fetches, structured answer | OK, complete and correct |

Run #1 executed immediately BEFORE the background failure, and run #3 immediately
AFTER. So this is not session-limit exhaustion and not a degraded session — flipping
only run_in_background flips the outcome.

SendMessage to the stalled agent asking for a partial report produced nothing: it
re-signalled idle instead of replying. TaskOutput could not resolve the agent by name.

4 occurrences over 2 days, identical shape each time: spawn succeeds -> agent goes idle
-> no report ever arrives.

Note on the workaround suggested by the title of #17011 ("...unless Write tool
explicitly called"): the original reporter tested that and documented it as failing —
"background agents don't reliably follow Write tool instructions". I want to flag this
because the title alone invites others to adopt a workaround that does not hold.

Documentation request: if this is not fixed soon, the Agent tool docs should state that
background agents' conversational output is unreliable, and that instructing them to
Write is NOT a dependable mitigation.

Relationship to existing issues (checked before filing):

• #72711 (OPEN) — "Nested background subagents stuck showing Running". Closest match, but

it covers NESTED subagents and the visible symptom is a stuck "Running" state in the UI.
This report is the NON-NESTED variant: agents spawned directly from the main session,
where the failure is silent (idle signalled, report never delivered) rather than visibly
stuck. Same platform (Windows), same run_in_background: true.

• #17147 (closed as duplicate) — output FILE empty (0 bytes). Different: my agent was

read-only and wrote no files; the lost output was the inline return itself.

• #17011 (closed as not planned / stale, labels: bug, has repro, platform:windows) —

same underlying symptom, closed for inactivity rather than fixed.

What Should Happen?

Background agent responses should be captured and delivered the same way blocking
execution captures them.

If the conversational return genuinely cannot be captured in background mode, the tool
should fail loudly at spawn time — refusing the task or emitting a clear warning —
rather than accepting the task, running it to completion, and silently discarding the
result.

Error Messages/Logs

No error is emitted. That is the core problem — the failure is silent.

The only signal received:

{"type":"idle_notification","from":"<agent-name>","idleReason":"available"}

Delivered twice for the same agent. No error, no warning, no partial output.

Steps to Reproduce

1. Spawn a Task agent with run_in_background: true and a read-only prompt that returns

its result as structured text (no file writes). Example: "grep this directory tree
for pattern X and return a markdown table of matches".

1. Wait. An idle_notification arrives with idleReason: "available".
2. No report is ever delivered.
3. Send the agent a SendMessage asking for a partial report — it re-signals idle

instead of replying.

1. Spawn the exact same task with run_in_background: false — it completes normally and

returns the full report in seconds.

The read-only aspect matters: because the agent writes no files, the report IS the
deliverable, so nothing is recoverable from disk.

Environment

• Claude Code Version: 2.1.216 (Claude Code)
• Claude Model: Opus
• Platform: Subscription (Claude Pro/Max) — NOT Anthropic API
• Operating System: Windows 11 (build 26200)
• Terminal/Shell: PowerShell
• Is this a regression: Not sure — no evidence it worked in an earlier version; #17011

reports the same symptom back in January, suggesting long-standing rather than recent.

Related issues

• #72711 (OPEN) — "Nested background subagents stuck showing Running" — closest match, but covers NESTED subagents with a visible stuck-Running symptom. This report is the non-nested variant with a silent failure (idle signalled, report never delivered).
• #17147 (closed as duplicate) — output FILE empty (0 bytes). Different: my agent was read-only and wrote no files; the lost output was the inline conversational return itself.
• #17011 (closed as not planned / stale, labels: bug, has repro, platform:windows) — same underlying symptom, closed for inactivity rather than fixed.

Additional Information

Environment detail: Windows 11 build 26200. Both git-bash and PowerShell tools available
in the session. Agent type general-purpose, no model override, no isolation setting.

On "is this a regression": marking Not sure deliberately. I have no evidence it worked in
an earlier version — I only started noticing the failures recently. #17011 dates from
January with the same symptom, which suggests this is long-standing rather than a recent
regression.

Happy to re-run the controlled A/B, provide agent IDs, or test a candidate fix.