TUI silence during parallel `Agent` tool calls when one is hook-rejected

Note: This issue was investigated and drafted with the help of Claude (had Claude search prior reports and the docs before filing).

Summary

When the orchestrator issues N parallel Agent tool calls in a single assistant message and one of them is rejected by a PreToolUse hook (or any other early-return path), the remaining N-1 agents run to completion silently — no UI indication of activity for the entire duration. The TUI appears frozen, indistinguishable from a hung session.

In my case: 5 parallel Agent calls in one assistant message; the first was hook-rejected; the other 4 ran for ~4 minutes each; during that ~4-minute window the TUI showed no spinner, no token counter, no per-agent status, no visible indication anything was running. I genuinely thought the session had hung.

Environment

• Claude Code with Opus 4.7 (1M context model: claude-opus-4-7[1m])
• macOS (darwin 24.5.0)
• iTerm2
• Date: 2026-05-11
• Custom PreToolUse hooks present in the project (relevant because the first agent's rejection is suspected to interact with the silence)

Why this is distinct from prior reports

This case overlaps with but is not identical to:

• #24580 — parallel subagents have no progress visibility; root mechanism explained internally (single-threaded turn loop; per-token progress events not surfaced) but the report doesn't cover the hook-rejection interaction
• #27916 — feature request for active subagent counter in statusline; not filed as a bug
• #12996 — blank screen during long operations; closed as not planned
• #21399 — parallel Explore agents hang with static spinner; closed as duplicate

The novel detail here: when one agent in the parallel batch is hook-rejected, that rejection appears to consume the single render event the TUI would have shown for the batch. The remaining agents then run with NO UI feedback whatsoever — measurably worse than the baseline "no progress indicator during parallel agents" behavior reported in #24580 (where at least the initial dispatch was visible).

Hypothesis: the TUI's render loop treats the hook-deny as the batch's "tool result" event and re-enters the wait state, with no subsequent render trigger until the next outer-turn tool result lands. So a 1-of-5 hook rejection ends up worse for visibility than a 0-of-5 case.

Suggested fix shape (not a hard requirement)

Either:

1. Each running parallel Agent should emit a periodic heartbeat / token-count update visible in the TUI. The underlying token-progress events already exist per #24580's internal explanation — they just aren't rendered.
2. When a parallel Agent batch has remaining in-flight agents after one returns/errors, the TUI should render a "N running, M complete" line in the status area until all return.
3. At minimum, distinguish "hook rejection of one agent in a batch" from "entire batch completed" in the render trigger logic — the current behavior conflates them.

References

• #24580 (parallel subagent progress visibility — closest match for the underlying mechanism)
• #27916 (feature request for subagent counter)
• #12996 (blank screen during long operations)
• #21399 (parallel Explore hang)
• #37521 (agent freeze on Opus 4.6)

Happy to provide more context, hook configs, or repro steps if useful.