[Bug] Tool/sub-agent results deliver with multi-minute buffering delay causing model busy-wait polling

Bug Description
Title: Tool/sub-agent results delivered with multi-minute buffering delay → model busy-waits with hundreds of no-op shell commands

Environment: Claude Code v2.1.157 · Opus 4.8 (1M) · macOS (darwin 25.5.0)

Summary:
Tool and sub-agent results intermittently deliver with a severe buffering delay — the result returns empty/pending to the model, then "flushes" minutes later. The model misreads the empty result as "work still running" and
busy-waits, emitting hundreds of no-op shell commands (echo "pollN $(date)", pgrep … | wc -l, true) to poll for completion. The polling is pure waste: the awaited work has already finished, and polling never makes a
buffered result arrive sooner.

Impact / severity:
In one github-pr-evaluator run, the model emitted ~500 no-op poll commands across four separate bursts and had to be manually interrupted. Every burst fired after the sub-agent it was "waiting for" had already completed.
In one burst it gave up on a buffered builder result and re-ran a 3-minute test gate in the foreground, duplicating finished work. This consumes large amounts of context, tokens, and wall-clock time, and makes long skill
runs effectively unusable.

Repro context:
A Claude Code skill that dispatches several sequential sub-agents within one turn — a custom project sub-agent plus apple-platform-build-tools:builder. The delay appears tied to sub-agent/tool-result delivery, not to any
single tool. It is intermittent (some runs are clean; others spiral).

Observed signature:
After dispatching a sub-agent, the main loop runs long streaks of commands like:
echo "POLL-MARKER-A $(date +%H:%M:%S)"; pgrep -fl 'xcodebuild|xctest' | wc -l
echo "post-poll125 $(date -u +%H:%M:%S)"
echo "merge-poll250 $(date -u +%H:%M:%S)"
then later narrates "All tool output has now arrived (it was buffered, not lost)."

Request:
Deliver sub-agent/tool results promptly, or surface an explicit "result pending" signal so the model waits instead of polling. A built-in circuit-breaker for repeated near-identical/no-op Bash calls within a turn would
also help (today there is none for PreToolUse).

Note: Prompt-level guidance does not mitigate this — in the captured run the model quoted its own instruction "a result that seems slow is buffered, not lost — wait, don't probe" and spiraled anyway.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.157
• Feedback ID: 5e5f0ed5-55a8-4393-a5c3-a786addbce7e

Errors

[]