Repository navigation
Bug: Multi-Session Hang - Only Latest CLI Session Works (WSL2 + OAuth) #13448
Description
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
- Open 3 separate terminal windows in WSL2
- Start
claudein each terminal - Give each session a task (e.g., "what is 2+2")
- Observe: Only the LAST session given a task responds
- 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:
- Something causes existing sessions' connections to be invalidated/closed
- The existing sessions do not recover or attempt to reconnect
- 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.
Reacted by mstfkrdnz, shun, asteroid-europa-ursula and Ian Cox
Activity
github-actions commentedon Dec 9, 2025
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
saadfaruque99 commentedon Dec 9, 2025
Possibly Related: #13287 reports similar multi-session blocking behavior on macOS.
Key Differences:
Lock acquisition failed)AggregateError,TLSSocket.socketErrorListener)The symptom is the same (only one session works at a time), but the underlying errors differ. These may be separate bugs with similar manifestation, or different symptoms of the same concurrency issue. Linking for visibility.
KCW89 commentedon Dec 14, 2025
Confirming this issue on macOS (not just WSL2)
Environment
Reproduction
Running 2-3 concurrent terminal sessions in different project directories. When switching between terminals, the inactive session(s) hang completely. Only the most recently active terminal responds.
Additional Observations
Initially, suspected custom hooks were causing the issue. After extensive debugging:
Result: Hooks weren't the root cause. The multi-session connection issue persists even with minimal hook configuration.
Symptoms Match Exactly
This confirms the issue affects macOS + Apple Silicon, not just WSL2/Linux.
github-actions commentedon Jan 15, 2026
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
github-actions commentedon Feb 14, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Feb 21, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.