[MODEL] Main agent burns consecutive no-op turns idle-waiting for a backgrounded subagent

### Preflight

- [x] I searched existing issues (closest matches are #80350 and #74050 — see "Related" below; this one is neither `ScheduleWakeup` nor `/loop`, it is plain empty assistant turns)
- [x] No sensitive information included

### Type of Behavior Issue

Subagent behaved unexpectedly — the main agent burns consecutive no-op turns idle-waiting for a backgrounded subagent instead of doing independent work.

### Environment

- Claude Code 2.1.241
- Windows 11, PowerShell
- Model: Opus 5 (1M context)
- Plan mode on, subagent spawned via the `Agent` tool with `subagent_type: Plan`

### What You Asked Claude to Do

I asked it to validate a dashboard side-panel design and produce a plan. Claude decided on its own to delegate the validation to a `Plan` subagent (`Plan(Validate dashboard side panel plan)`), which was backgrounded.

### What Claude Actually Did

After spawning the subagent, it produced **eight consecutive turns that did nothing but announce it was waiting**:

```
● Plan(Validate dashboard side panel plan)
⎿ Backgrounded agent (↓ to manage · ctrl+o to expand)
Thought for 31s, read 2 files, ran 1 shell command

● Updated plan
⎿ /plan to preview

● I'm waiting for the Plan agent's validation. Thought for 16s, read 2 files
● I'm waiting for the Plan agent to return. Thought for 21s, read 1 file, ran 2 shell commands
● The Plan agent is still running; waiting for it. Ran 3 shell commands
● I'm waiting for the Plan agent's result. Thought for 22s, ran 4 shell commands
● The Plan agent is still running; waiting for it. Thought for 7s, ran 3 shell commands
● I'm waiting for the Plan agent to return. Thought for 8s, read 1 file, ran 4 shell commands
● I'm waiting for the Plan agent's result. Thought for 1m 33s, ran 1 shell command
● The Plan agent is still running; I'm writing the plan with what I have and will cross-check when its result arrives.
⎿ Interrupted · What should Claude do instead?
```

(The transcript is Turkish; the lines above are translated. The screenshot below is the original — the red lines mark every wasted turn, all converging on the same non-event.)

Notes:

- These are not tool-blocked turns. Each one *ended* — a full assistant turn, thinking time included, whose entire user-visible content is "I'm still waiting."
- The thinking and shell calls in between are not progress on the task; they are re-checks of whether the agent had returned.
- It only started doing real work ("writing the plan with what I have") on the ninth turn, at which point I interrupted.
- Cost of the wait: ~7 minutes wall clock and 18% of the context window, for zero output.

### Expected Behavior

The system prompt already says a subagent "runs in the background" and "you'll be notified when one completes." The model should therefore either:

1. spawn the subagent and immediately continue with independent work in the same turn, or
2. yield the turn once and stay silent until the completion notification arrives — not emit N status-only turns,

and never spend a turn whose only content is "still waiting." Polling a harness-tracked background task is exactly what the notification exists to replace.

A harness-side guard would help too: if an assistant turn produces no tool calls and no user-actionable text while a tracked subagent is pending, it should not be billed as a turn / consume context.

### Related

- #80350 — agent calls `ScheduleWakeup` prematurely instead of waiting for subagent notifications (same root cause, different symptom: there it schedules a wakeup, here it just spins turns)
- #74050 — main agent uses `/loop` to wait
- #81002 — `/simplify` hangs waiting for subagents

### Screenshot

Reproduce the backgrounded Agent-tool scenario in Plan mode and trace how pending subagent notifications are handled after the Agent tool returns. Compare the repeated status-only turns with the expected notification or single-yield behavior. Done means the main agent continues useful work or remains silent until completion, without emitting repeated no-op turns or consuming billed context for them.

Scritto dal modello di indicizzazione a partire dal testo della issue.