[BUG] Claude Code hangs indefinitely in local console sessions on Windows — but works over SSH on the same machine

Status Fixed / completed
Reported on v2.1.235
Maintainer reply None cached
Activity 1 comment · opened Aug 19, 2026 · closed Aug 19, 2026

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.

  1. On Windows 11, open a local console (Windows Terminal, conhost, cmd.exe, or

PowerShell — all four reproduce).

  1. cd ~
  2. Run:
   claude -p "hi"
  1. 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:

  1. Run claude
  2. The TUI launches normally and /status renders correct account and model

information.

  1. Type any message and press Enter.
  2. The spinner turns red and no response ever arrives.

Contrast case (this is the useful part):

  1. From another device, SSH into the same Windows machine (I used Termius).
  2. Run the same claude -p "hi" there.
  3. 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 443 succeeds
  • Proxy env vars — none set (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NODE_EXTRA_CA_CERTS)
  • Server-side incident — status page all operational; claude update reaches

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.ps1 npm shim — invoking claude.exe directly reproduces
  • Config state — ~/.claude renamed and regenerated from scratch
  • Reinstall — npm uninstall -g then npm install -g
  • Reboot
  • Stale processes — killed all claude processes, including four that refused

SIGKILL without admin rights (one of them in session 0)

  • MCP servers — --strict-mcp-config --mcp-config with {"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 sshd stopped

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 to
powershell.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.

claude-only.zip

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗