Claude CLI subprocess silent-hang: zero stdout for 3+ minutes (intermittent)

Summary

We invoke claude.exe as a subprocess from a PowerShell automation framework (Windows 11, Claude Code v2.1.x range). Intermittently, the subprocess produces zero stdout bytes for 3+ minutes before either eventually producing output or being killed by our wall-clock timeout guard. Same prompt + same model + same environment will succeed on one invocation and silent-hang on the next.

Environment

• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell 5.1 invoking claude.exe via System.Diagnostics.Process
• Account: Claude Max plan, long-lived token (setup-token via env var)
• Model: sonnet (Claude Sonnet 4.6)
• Invocation pattern: claude -p with prompt body read from a temp file (PAYLOAD_PATH reference), no interactive flags
• Prompt size: ~16KB
• Expected output: JSON ~4-8KB

Symptom (Repeatable Pattern, Intermittent Trigger)

1. PowerShell spawns claude.exe with RedirectStandardOutput = true
2. Process starts cleanly, exits to background
3. Zero stdout bytes for 3+ minutes (we monitor every 500ms)
4. No stderr output either
5. Process kept alive (not crashed; CPU usage minimal)
6. Eventually: either (a) starts producing tokens normally and completes, OR (b) hangs indefinitely until we kill it

Frequency

Roughly <1% of all subprocess invocations in our production automation. Hit it 2x in one hour during a heavy-use session on 2026-05-12 (entity-extraction skill, ~30 invocations across the day). Most of the day, same skill ran cleanly.

Mitigation We've Built

We added retry logic to our wrapper:

• Wall-clock timeout: 5 minutes total
• Stdout-silence guard: kill if 0 stdout bytes for 3 minutes
• 4 attempts total (3 retries after first), exponential backoff (30s → 60s → 120s → 240s)

This helps recover from one-off hangs but doesn't eliminate the underlying issue. Today's session hit the hang on attempt 1 AND attempt 2 back-to-back before recovering on a later scheduled retry.

What We've Ruled Out

• Not a prompt-size issue (succeeds with same payload most of the time)
• Not a network issue (other concurrent network ops fine; claude --version instant)
• Not a credential issue (auth check passes pre-spawn)
• Not a CPU/RAM contention issue (180GB RAM available, minimal load)
• Not a Windows process model issue (same pattern works for hundreds of other subprocess invocations daily)

Questions for the Anthropic Team

1. Is there a client-side way to detect the hang earlier than "no stdout for N minutes"? E.g., a heartbeat probe to the local CLI process to verify it's not stuck in a network wait?
2. Is there a recommended graceful-recovery flag we can pass that retries the underlying API call without spawning a new process (which costs ~12s setup time)?
3. Are there diagnostic env vars we can set (CLAUDE_DEBUG=1, CLAUDE_LOG_LEVEL=trace, etc.) that would capture what the CLI is doing during the hang for later reporting? We can capture and share those logs the next time it hits.
4. Is the hang pattern known to your team? If so, any expected fix release timeline?

Why This Matters For Us

We run ~50-100 claude subprocess invocations per day across scheduled automation (transcript syncing, email manager, entity propagation, system audits). Even <1% failure rate means we hit the hang roughly daily. The retry logic absorbs most of it, but the time cost (waiting through 3+1 min stdout-silence windows + backoff) adds up.

Happy to provide more detail, share PowerShell wrapper code, or run instrumented test invocations to capture data for you. Reachable via this issue thread or [andrew@gosunrise.com](mailto:andrew@gosunrise.com).

Thanks!