[BUG] Claude Code sessions freeze locally until another session receives input — Desktop app & VS Code only (not web)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
<html><head></head><body><h1>Concurrent Claude Code sessions freeze mid-"thinking" until another session receives input</h1>
<h2>Summary</h2>
<p>When I run multiple Claude Code sessions at once in the Claude Desktop app and the VS Code extension, a session will freeze mid-response ("thinking") and stay stuck indefinitely. It resumes the instant I type into a different session (e.g. typing "hey" in another pane un-sticks the frozen one). The web app is never affected. I have a screen recording attached demonstrating the "hey" example.</p>
<h2>Environment</h2>
<ul>
<li>macOS (Darwin 25.5.0), 14-core Apple Silicon Mac</li>
<li>Claude Desktop app (bundled <code>claude-code</code> 2.1.215)</li>
<li>VS Code extension <code>anthropic.claude-code</code> 2.1.216</li>
<li>Typically 3–5 concurrent sessions across Desktop + VS Code + terminal, one account</li>
<li>No proxy; home network; direct connection to the API</li>
</ul>
<h2>Reproduction</h2>
<ol>
<li>Have several Claude Code sessions open in Desktop/VS Code.</li>
<li>Send a message in one session — it hangs on "thinking."</li>
<li>It stays frozen until I type anything into another session, at which point the frozen one immediately continues.</li>
</ol>
<h2>Diagnostics already performed (to save your team time)</h2>
<p>I instrumented my machine while reproducing the freeze. The following were measured and ruled out as causes:</p>
Checked | Result
-- | --
CPU / core saturation | Ruled out — 14 cores, sessions idle at ~0% CPU
macOS App Nap | Disabled NSAppSleepDisabled for both apps + relaunched; issue persists
Deadlock / held mutex | Ruled out — sample shows main thread parked in normal idle kevent64, no held lock
Shared config-file lock (~/.claude.json) | Ruled out — no processes hold the file open
File descriptor / socket / port exhaustion | Ruled out — ~44 fds vs 1M limit; 18–56 connections; ~16k ephemeral ports free
Proxy / gateway | None configured; direct connections
DNS / mDNSResponder | Healthy — 3–7ms system resolves; fresh TLS connect to api.anthropic.com ~150–280ms
<h2>Key finding (network byte trace)</h2>
<p>I recorded per-process network bytes (via <code>nettop</code>, 1-second resolution) across a full freeze→unblock cycle. During the entire cycle the only Claude network activity was a 39-byte keep-alive every ~14 seconds, with 0 bytes inbound. When the frozen session resumed, no inbound bytes arrived — i.e. it was not waiting on the server to stream a response.</p>
<p><strong>Conclusion from the data:</strong> the freeze and its recovery are entirely local, with no network I/O involved. Combined with the "unblocks when another session gets input" behavior and the fact that it's exclusive to Desktop/VS Code (never the web app), this points to a local event-loop / scheduling issue in how the app services multiple concurrent sessions — a pending session only advances when activity in another session pushes the shared event loop forward.</p>
<h2>What I'd like</h2>
<p>Confirmation of whether this is a known issue with concurrent local sessions, and a fix or workaround. Happy to provide further traces (thread samples, debug logs) on request.</p></body></html>
What Should Happen?
Each Claude Code session should run independently. When I send a message in one session, it should process and respond on its own, regardless of what my other open sessions are doing
— I should not have to type into a different session to "unstick" it. Multiple concurrent sessions in the Desktop app and VS Code should behave like separate sessions in the web app:
one session's progress should never be blocked waiting on activity in another. A session that is "thinking" should continue to completion without any input from me elsewhere.
Error Messages/Logs
## Error Messages / Logs
No error messages are produced — the session hangs silently with no crash, no error, and no log entry. Below are the relevant diagnostic logs I captured while reproducing the freeze.
**1. Per-process network byte trace** during a full freeze→unblock cycle (`nettop`, 1s resolution). Only a 39-byte keep-alive every ~14s, 0 bytes inbound — no response traffic when the session unblocked:
14:18:16 Claude bytes_in=0 bytes_out=39
14:18:30 Claude bytes_in=0 bytes_out=39
14:18:44 Claude bytes_in=0 bytes_out=39
14:18:58 Claude bytes_in=0 bytes_out=39
**2. Thread sample of a stuck session** (`sample <pid>`) — main thread parked in a normal idle event-loop wait (no deadlock, no held lock, no active work):
Thread (main): DispatchQueue_1: com.apple.main-thread
start (dyld)
...
kevent64 (libsystem_kernel.dylib) <- idle, waiting for an event
**3. Resource / limit checks** (all well within bounds):
open file descriptors per session : 44–47 (soft limit 1,048,576)
established TCP connections : 18–56 total
free ephemeral ports : ~16,000
proxy configured : none
system DNS resolve (getaddrinfo) : 3–7 ms
fresh TLS connect api.anthropic.com: 150–280 ms
**4. Process states during freeze:** stuck sessions in normal interruptible sleep (`S` / `S+`) at ~0% CPU — idle, not spinning.
**Summary:** there is no error output; the logs show the session sitting idle in its event loop with zero network I/O, and it only advances when another session receives input. Full raw traces available on request.Steps to Reproduce
https://www.loom.com/share/9eb4c13926fc453cbdeb174ec72ae3e6
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.216
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
3 Comments
Same issue here, great report
The cross-session input dependency you are describing -- where one frozen session unblocks when another receives input -- points to a shared event loop or polling mechanism that services multiple sessions from the same process. The web app not exhibiting this is consistent: the web interface likely runs each session with independent polling, while the Desktop app and VS Code extension multiplex sessions through a shared daemon.
The practical consequence in multi-agent workflows is worse than occasional freeze: if you are running an orchestrator session alongside 3-4 worker sessions, any period where the orchestrator is the only session receiving input can stall all worker sessions mid-turn. The freeze does not surface as an error -- it looks like the agent is "thinking" -- so it is hard to distinguish from a slow response on a complex task.
Worth noting: does the freeze happen only when the other sessions are in a "waiting for input" state, or also when they are mid-generation? If it only freezes when others are idle, the dependency may be in the heartbeat/keepalive path rather than the event loop itself. That would narrow the fix considerably.
The v2.1.216 changelog entry for the daemon session roster handling (Background-session daemon fd fix, #79920) might be touching adjacent code. Worth checking if this regressed on the same version.
this helps prevent the freeze.
https://github.com/anthropics/claude-code/issues/79920#issuecomment-5040759566