[BUG] CLI hangs silently on WSL2 - streaming response never processed

[dp-web4]

Description

Claude Code CLI hangs indefinitely on WSL2 when making any API call. No output, no error message. Affects interactive mode and claude -p.

Working on Mar 23 with v2.1.81 and same Windows install. Broke between Mar 23-25.

Environment

• Windows 11 Pro 10.0.26200 / WSL2 Ubuntu
• CLI versions tested: 2.1.80, 2.1.81, 2.1.83 — all hang
• Auth: OAuth (Max subscription), token valid, auth status confirms logged in
• Windows Updates: KB5085516 (Mar 22), KB5083532 (Mar 11) — ruled out since CLI worked Mar 23

What works vs what does not

Environment	Status
Claude Desktop App (Windows)	Works
curl to api.anthropic.com from WSL2	Works
Raw Node.js HTTPS with same token	Works (200)
CLI v1.0.124 on another WSL2 machine	Works (old scopes)
CLI v2.1.80/81/83 on WSL2	Hangs

Key findings

1. API response arrives but CLI never processes it. ANTHROPIC_LOG=debug shows request sent, no response logged. strace confirms bytes received on socket. CLI sits in event loop forever.

2. Raw Node.js proves API works. Same token, same headers, same endpoint — returns 200 instantly from WSL2.

3. CLI silently swallows errors. When streaming endpoint returns 400/401, CLI hangs instead of showing error. This is the core UX bug.

4. Server-side changes detected. Without oauth-2025-04-20 beta header, API returns "OAuth authentication is currently not supported." With it, Haiku works but Sonnet/Opus return 400 with generic "Error" message.

5. OAuth scope difference. Working v1.0.124 uses scopes user:inference, user:profile. Broken v2.1.83 uses expanded scopes including user:file_upload, user:mcp_servers, user:sessions:claude_code.

6. v2.1.81 worked Mar 23, hangs today — same binary, same Windows. Points to server-side change.

Repro

claude -p "say hello"  # hangs indefinitely
ANTHROPIC_LOG=debug claude -p "hi" 2>&1  # shows request, no response

Additional issues found

• claude auth login redirect never completes on WSL2, no paste-code fallback
• --bare flag reports "Not logged in" despite valid credentials
• Cloudflare blocks manual OAuth token exchange from WSL2

Expected

Display error message and exit non-zero, not hang silently.

[github-actions]

Found 3 possible duplicate issues:

1. Claude CLI Hangs or Becomes Unresponsive in WSL (Intermittent Issue) #619
2. [BUG] Claude Code hangs indefinitely when API streaming connection stalls (no read timeout) #25979
3. [Bug] Claude Code hangs indefinitely during processing with no error output #13240

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[dp-web4]

Update: Root cause identified for native Windows CLI hang (same symptoms, different cause)

Continuing investigation from the original WSL2 report — After extensive debugging, we identified the root cause via Wireshark packet capture.

Root cause: Path MTU black hole

The CLI sends a large initial HTTP payload (~14KB burst in 5 packets of ~2776 bytes each) immediately after the TLS handshake. On networks where the effective path MTU is below 1500, these packets are silently dropped — no ICMP "Fragmentation Needed" is returned, so PMTUD fails. The server ACKs the TLS handshake data but never acknowledges the application data. The client retransmits at the same size indefinitely until timeout → ECONNRESET.

Wireshark evidence:

• TCP handshake: works (small packets)
• TLS handshake: works (Client Hello ~602 bytes, ACKed)
• Application data: 5x ~2776-byte bursts → server ACKs only up to the TLS boundary, never the app data
• Retransmissions at 1388 bytes → also never ACKed
• Client eventually RSTs after exhausting retries

Why CLI-only (desktop app unaffected):
The desktop app (Chromium) either sends smaller initial requests or handles PMTUD more gracefully via Happy Eyeballs / connection racing. Chromium's HTTP stack is more resilient to MTU issues than the compiled Node.js binary's stack.

Why network-specific:
Only affects networks with sub-1500 effective MTU on the path to 160.79.104.10. Home networks and mobile hotspots typically have clean 1500-byte paths.

Test environment:

• 3 Windows 11 machines on the same office network
• Claude Code v2.1.86 (standalone binary)
• 2 of 3 machines affected (different severity — one failed CLI only, one failed both CLI and desktop)
• All machines worked on mobile hotspot

Workaround:

netsh interface ipv4 set subinterface "Ethernet 2" mtu=1400 store=persistent

(Replace "Ethernet 2" with your adapter name from netsh interface ipv4 show subinterfaces)

Suggested fix:
The CLI binary should either advertise a lower TCP MSS (e.g., 1400), break up the initial HTTP request into smaller chunks, or implement PMTUD black hole detection with segment size reduction on retransmit.