claude -p --effort high intermittently hangs ~600s on long-reasoning prompts (Windows-specific; macOS unaffected)

Environment

• Claude Code CLI, headless print mode: claude -p "<prompt>" --model claude-sonnet-4-6 --effort high --output-format json
• OS: Windows 11. Invoked as a subprocess (stdin = DEVNULL, captured stdout/stderr), in a loop of sequential calls.
• Also reproduced on claude-opus-4-8. Subscription auth.

Summary

On Windows, claude -p at high effort intermittently hangs ~600–615s (suspiciously fixed, ±2s) on prompts that induce a long hidden-reasoning phase, then returns a valid (often short) response. The same prompts complete in ~30–90s on macOS and ~37s when run standalone on Windows. So the ~600s is overhead, not reasoning.

Reproduction

1. On Windows, issue a sequence of claude -p high-effort calls.
2. Use prompts that trigger long hidden reasoning (controversial/nuanced topics), e.g.:

"Examine the body of research concerning the psychological effects of social media usage on adolescent mental health, addressing both negative and positive dimensions."

1. Intermittently, some calls take ~615s instead of ~30–40s, with small output (e.g. 60–80 tokens).

Observations

• Same prompt, wildly different times: ~37s standalone vs ~615s inside a sequential loop (Windows). So it's context/overhead, not the prompt or reasoning.
• Length-correlated: only long-reasoning prompts hit it; short prompts (~15–50s) complete normally. The longer the hidden-reasoning phase, the more likely the hang.
• Windows-specific: on macOS the identical prompts run 33–97s with no ~600s hang.
• ~615s is suspiciously fixed (±2s across different prompts) → looks like a ~600s timeout/cap, not natural variation.
• The call eventually returns valid output at ~615s (not a permanent hang).

Likely cause (hypothesis)

A ~600s connection/idle/streaming timeout in the Windows claude -p path that triggers when the hidden-reasoning phase is long enough that no output tokens stream for ~600s (idle) — the connection stalls to a ~600s cap, then completes. macOS does not exhibit it.

Secondary (may be related — Windows process handling)

A parent process's subprocess timeout does not terminate the hung claude -p on Windows: child/grandchild processes appear to hold the stdout pipe, so the parent's timeout-cleanup blocks (the call runs its full ~615s regardless of the parent timeout). Suggests the claude -p process tree isn't cleanly killable via the parent on Windows.

Impact

Severe wasted tokens/quota and wall-clock time: each affected call burns ~600s of quota for a tiny result; a batch measurement consumed most of a usage window on a handful of these. Standalone/macOS are unaffected, so it's specific to sequential headless claude -p use on Windows.