[BUG] Claude Code hangs indefinitely in local console sessions on Windows — but works over SSH on the same machine
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?
On Windows 11, Claude Code hangs indefinitely when run from a local console
session, but works normally when the session is an SSH session to the same
machine — same binary, same user account, same credentials, same network.
In the failing case, the request does reach the server and the response does
come back. A packet capture shows TLS established with api.anthropic.com and
219 kB of response payload received. Despite that, nothing is ever written
to stdout. The process then reopens connections and repeats the whole cycle
roughly every 30 seconds, forever.
The failure is completely silent: no error message, no exit code, and --debug
produces no output at all — not even the local startup logging that normally
precedes the request.
While hung, the process holds 434 MB and has burned 3.5 s of CPU (so the
response was received and at least partially processed), and all 25 of its
threads are blocked — nine of them in EventPairLow, an ALPC wait. It spawns
no child processes, so whatever it is waiting on is a system service rather
than a helper process of its own.
I ruled out, by testing, all of the following: network path, proxy environment
variables, server-side incident, terminal emulator, shell version, PowerShell
profile, the claude.ps1 npm shim, config state (~/.claude regenerated from
scratch), full reinstall, reboot, leftover processes, MCP servers, model
selection, account limits, output format, and stdout redirection. The full list
with details is in the Additional Context section.
What Should Happen?
claude -p "hi" should print the model's reply to stdout and exit.
In interactive mode, sending a message should stream the reply into the TUI.
This works correctly when the session is an SSH session to the same machine —
same binary, same account, same credentials — so the expectation is that a
local console session behaves identically.
Error Messages/Logs
There are no error messages. That is part of the problem — the failure is
completely silent.
- `--debug` prints nothing at all, not even the local startup logging that
normally appears before the request is sent.
- stdout and stderr redirected to files (`1> out.txt 2> err.txt`) both come
back empty (0 bytes).
- `~/.claude/debug/` is never created.
- No exit code is produced, because the process never terminates on its own.
Since no log channel produces anything, I captured evidence externally instead.
**1. Packet capture — the request goes out and the response comes back**
Captured with `netsh trace`, converted with `etl2pcapng`, analyzed with tshark.
DNS resolution:
21.223878000 api.anthropic.com
22.797030000 api.anthropic.com
31.811737000 mcp-proxy.anthropic.com
TLS handshakes to 160.79.104.10 (api.anthropic.com), showing a retry burst
at t=30.88 and an identical one at t=60.5 — a ~30 second retry cycle:
30.749471000 160.79.104.10 api.anthropic.com
30.881578000 160.79.104.10 api.anthropic.com
30.881969000 160.79.104.10 api.anthropic.com
30.882275000 160.79.104.10 api.anthropic.com
30.882559000 160.79.104.10 api.anthropic.com
30.882866000 160.79.104.10 api.anthropic.com
30.886603000 160.79.104.10 api.anthropic.com
TCP conversation statistics (`tshark -q -z conv,tcp`):
192.168.0.2:64602 <-> 160.79.104.10:443 sent 225 kB / recv 219 kB (t=30.868, 48.7s)
192.168.0.2:54289 <-> 160.79.104.10:443 sent 220 kB / recv 204 kB (t=60.508, 23.6s)
**219 kB and 204 kB of response payload are received.** Not a single byte
reaches stdout.
**2. Process state while hung**
Id HandleCount CPU PrivateMemorySize64
19524 374 00:00:03.4687500 434266112
434 MB resident and 3.5s of CPU means the response was received and at least
partially processed. Sampling CPU 30s apart shows it creeping up
(3.469s -> 3.625s), so this is a retry loop rather than a hard deadlock.
All 25 threads are blocked:
ThreadState WaitReason Count
Wait EventPairLow 9
Wait Unknown 12
Wait UserRequest 2
Wait ExecutionDelay 1
Nine threads are in `EventPairLow` (ALPC wait). The process spawns no child
processes, so the ALPC peer is a system service rather than a helper it
started itself.
Steps to Reproduce
No project files or special configuration are needed — this reproduces in the
home directory with no .claude project settings present.
- On Windows 11, open a local console (Windows Terminal, conhost, cmd.exe, or
PowerShell — all four reproduce).
cd ~- Run:
claude -p "hi"
- The command hangs. Nothing is printed, no error appears, and the process
never exits. Killing it with Ctrl+C is the only way out.
Interactive mode fails the same way:
- Run
claude - The TUI launches normally and
/statusrenders correct account and model
information.
- Type any message and press Enter.
- The spinner turns red and no response ever arrives.
Contrast case (this is the useful part):
- From another device, SSH into the same Windows machine (I used Termius).
- Run the same
claude -p "hi"there. - It works correctly and prints the reply.
Same binary, same user account, same credentials, same network. Only the
session type differs.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Not a clean regression. The same symptom occurred on Aug 1 and Aug 18, 2026, and on both occasions it cleared after logging out and back in. On Aug 19 the same recovery no longer works. I did not record the exact versions on those earlier dates.
Claude Code Version
2.1.235 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Every item below was tested and did not change the behavior:
- Network path —
Test-NetConnection api.anthropic.com -Port 443succeeds - Proxy env vars — none set (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NODE_EXTRA_CA_CERTS)
- Server-side incident — status page all operational;
claude updatereaches
the server successfully during the same period
- Terminal emulator — Windows Terminal, conhost, cmd.exe
- Shell — PowerShell 7.6.5 and Windows PowerShell 5.1
- PowerShell profile — reproduces with
-NoProfile; profile contains one
unrelated alias
- The
claude.ps1npm shim — invokingclaude.exedirectly reproduces - Config state —
~/.clauderenamed and regenerated from scratch - Reinstall —
npm uninstall -gthennpm install -g - Reboot
- Stale processes — killed all
claudeprocesses, including four that refused
SIGKILL without admin rights (one of them in session 0)
- MCP servers —
--strict-mcp-config --mcp-configwith{"mcpServers":{}} - Model — Fable 5, Opus 5, Sonnet 5
- Account limits — usage well under quota
- Output format —
--output-format json - stdout redirection —
Start-Process -RedirectStandardOutput - OpenSSH service — reproduces with
sshdstopped
Context that may or may not be relevant: the day before this started, I was
setting up remote terminal access on this machine (Windows OpenSSH server, and
an attempt at ttyd). HKLM:\SOFTWARE\OpenSSH\DefaultShell is set topowershell.exe (5.1). Stopping the sshd service does not fix the hang, but I
mention it since the timing lines up and remote-terminal setup touches console
handling.
A filtered packet capture containing only the Anthropic traffic is attached.
Happy to run any additional diagnostics.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗