Bug: Multi-Session Hang - Only Latest CLI Session Works (WSL2 + OAuth)

Bug Report: Multi-Session Hang - Only Latest Session Works

Summary

When running multiple concurrent Claude Code CLI sessions, only the most recently active session maintains API connections. Other sessions become unresponsive ("hung") with zero API connections.

Environment

| Property | Value |
|----------|-------|
| Claude Code Version | 2.0.62 |
| OS | Ubuntu 24.04 LTS (WSL2) |
| Kernel | 5.15.x-microsoft-standard-WSL2 |
| Platform | x86_64 (Windows 11 + WSL2) |
| Authentication | Claude Max subscription (OAuth) |

Steps to Reproduce

1. Open 3 separate terminal windows in WSL2
2. Start claude in each terminal
3. Give each session a task (e.g., "what is 2+2")
4. Observe: Only the LAST session given a task responds
5. The other 2 sessions become completely unresponsive

Expected Behavior

All 3 sessions should work independently and respond to commands.

Actual Behavior

• Only the most recently active session works
• Other sessions hang indefinitely
• Pressing Escape in hung sessions shows "process has stopped"
• claude -c (resume) also fails for hung sessions
• Only starting a completely new session works

Diagnostic Evidence

Connection Analysis

When examining socket connections during the hang:

Session 1 (started first):  0 API connections  → HUNG
Session 2 (started second): 0 API connections  → HUNG
Session 3 (started last):   1+ API connections → WORKING

The hung sessions have zero connections to Anthropic's API servers.

Process State

All processes show identical states:

• State: S (sleeping)
• Syscall: 281 (epoll_pwait) - waiting for I/O events
• But hung sessions have no connections, so no events will ever arrive

Debug Log Errors

Frequent AggregateError from TLS socket layer:

[ERROR] AggregateError: AggregateError
    at emitErrorEvent (node:_http_client:104:11)
    at TLSSocket.socketErrorListener (node:_http_client:518:5)

Also observed:

[ERROR] Error streaming, falling back to non-streaming mode: Connection error.

What We Ruled Out

| Hypothesis | Test | Result |
|------------|------|--------|
| Idle connection timeout | Applied TCP keepalive (60s) | Did not fix |
| Session file accumulation | Cleaned old session files | Did not fix |
| OAuth token issue | Full logout/login cycle | Did not fix |
| Network connectivity | curl to API works fine | Not the issue |
| Rate limiting | No 429 errors in logs | Not the issue |

Root Cause Hypothesis

The bug appears to be in Claude Code's connection management when multiple instances share the same OAuth credentials. When a new session makes an API request:

1. Something causes existing sessions' connections to be invalidated/closed
2. The existing sessions do not recover or attempt to reconnect
3. They remain in epoll_pwait forever, waiting for events on dead/non-existent connections

System Resources During Hang

• CPU: ~99% idle (not resource exhaustion)
• Memory: No pressure
• Swap: Unused
• File descriptors: Normal counts

Workarounds

• Use only 1 CLI session at a time
• VSCode extension appears more stable for multi-session scenarios

Impact

• Severely limits productivity for users who work with multiple terminal sessions
• Forces single-session workflow
• Requires manual process termination to recover

Additional Information

Detailed diagnostic data (process states, socket dumps, debug logs) available upon request.