[BUG] Subagent SSE streams stall silently at scale; connections stay ESTABLISHED with zero inbound bytes (dynamic workflows, v2.1.214, Windows 11)

Environment: Claude Code 2.1.214 (native installer; verified by running the
superseded binary the installer archived when it auto-updated to 2.1.215 at ~17:33 the
same day, after the window; the affected session's process kept running 2.1.214).
Windows 11 Pro 26200, direct connection (no proxy/VPN), Wi-Fi (Intel BE200). Session ID
available for internal lookup: 1e9a49b9-9bd9-4c2c-9ab8-ab299386c4f8.

Summary: During dynamic-workflow runs with ~10 parallel subagents (reasoning effort
max and xhigh), subagent SSE streams repeatedly stopped delivering with no error event
during a roughly 95-minute window (2026-07-19, ~15:45-17:20 UTC-8). TCP connections to
the Anthropic API endpoint stayed ESTABLISHED while process-level inbound byte flow measured
0.0-0.1 KB/s over repeated 6-8 s sampling windows, and agent transcripts froze. The main
interactive session in the same process was unaffected throughout. Short subagent turns
(tool-call round trips) continued to succeed during the window; only long
thinking/generation turns starved. A user-visible 529 and a brief "model temporarily
unavailable" from a secondary model occurred inside the same window; status.claude.com
showed all systems operational.

Local causes excluded during the window:

• 10 parallel rate-limited HTTPS downloads (Cloudflare) sustained 10 minutes flawlessly

on the same network at the same time.

• A non-Anthropic LLM API delivered a non-streaming HTTPS response after 102 s of

silent wire mid-window without issue (same machine, Python).

• After the window (~17:30), a single-subagent probe completed a ~7-minute thinking turn

normally, and a 10-wide workflow subsequently ran with normal progress (aside from two
transient agent failures the client retried automatically), so the machine, network,
and account handle the identical shapes outside the window.

What worked: stalled subagents were converted into visible errors and retried on
roughly 10-25 minute cycles (consistent with the v2.1.210 mid-stream stall failsafe);
runs self-healed rather than hanging for hours. We have since set
CLAUDE_CODE_RETRY_WATCHDOG=1 and a tighter stream idle timeout for future runs, though
those settings have not been exercised yet.

Two smaller items:

1. References to the stream idle timeout variable appear under two names

(CLAUDE_STREAM_IDLE_TIMEOUT_MS and CLAUDE_CODE_STREAM_IDLE_TIMEOUT_MS). Which is
canonical, and what is the default?

1. During long silent thinking turns, the /workflows board reported stale idle times and

token counts (e.g. "idle 14m" while the agent transcript had fresh writes minutes
old), which makes healthy runs look dead and invites unnecessary kills. Live stream
state (bytes/events received) in that view would help operators a lot.

Happy to provide the byte-flow samples, socket tables, and timestamps collected during
the window if useful.