[BUG] Windows native install/CLI hangs indefinitely with zero network activity (confirmed via Process Monitor)

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?

Summary

On a specific Windows 10 machine, both claude (bare, interactive) and the installer's
internal claude-2.1.259-win32-x64.exe install latest step hang indefinitely (observed
for hours) with no error, no output, and — confirmed via Process Monitor — zero network
activity of any kind (no DNS, no TCP, no UDP events at all for the process). claude
--version and claude --help work correctly.

Environment

• OS: Windows 10, build 19041 (receiving regular cumulative updates, most recent Aug 2026)
• Domain-joined machine (Active Directory)
• PowerShell 5.1 (ConsoleHost), also reproduced in cmd.exe
• CPU: Intel Xeon E5-2690 v3 (AMD64, 64-bit OS and process confirmed via

[Environment]::Is64BitOperatingSystem / Is64BitProcess = True/True)

• RAM: 10GB total, 5.6GB free at time of test
• Disk: 17.99GB free
• Windows Defender real-time protection: disabled; no third-party AV
• No VPN, no configured proxy (HTTP_PROXY/HTTPS_PROXY unset)
• Claude Code version: 2.1.259 (native installer, ~/.local/bin/claude.exe)

Steps to reproduce

1. Install via irm https://claude.ai/install.ps1 | iex (or run existing claude)
2. Installer prints "Setting up Claude Code..." and never progresses
3. Bare claude (after successful install elsewhere) also hangs indefinitely;

claude --version and claude --help return instantly and correctly

What was ruled out (extensive testing)

• Network reachability: Test-NetConnection api.anthropic.com -Port 443 succeeds;

raw TLS handshake via System.Net.Security.SslStream to api.anthropic.com succeeds
and returns the genuine CN=api.anthropic.com certificate (no TLS interception/MITM)

• Invoke-WebRequest to both claude.ai and api.anthropic.com succeeds instantly

(after forcing [Net.ServicePointManager]::SecurityProtocol = Tls12, though this
didn't fix the native binary)

• DNS resolves correctly (A and AAAA records for api.anthropic.com)
• Disk space, RAM: both plenty free
• Antivirus: Defender real-time protection off; no 3rd-party AV
• No zombie/duplicate claude.exe processes contending for a lock (tested with a single

clean instance)

• Not a PowerShell console/legacy-mode issue (reproduced identically in cmd.exe)
• Not a code page issue (chcp 65001 made no difference)
• Not a corrupted ~/.claude config (reproduced after fully removing and letting it

regenerate from scratch)

• Not a conflict with the Claude Desktop app (reproduced after fully uninstalling

Claude Desktop)

• Not the "shell config is a directory" claude doctor/claude update hang bug

($PROFILE does not exist; not a directory)

• Not 32-bit PowerShell ([Environment]::Is64BitProcess = True)
• Not Teredo/IPv6 happy-eyeballs (disabled Teredo via `netsh interface teredo set

state disabled`; hang reproduced identically afterward)

• Not TLS interception via a locally-installed root CA (the domain machine does have

a self-signed CN=<hostname>.<domain>.local cert in the Trusted Root store, but
direct SslStream test to api.anthropic.com returns the real Anthropic cert, so this
cert is not intercepting external HTTPS traffic)

Process Monitor findings (most important)

Captured a full PML trace of the claude-2.1.259-win32-x64.exe install latest child
process spawned by the installer (parsed the .PML programmatically to confirm). The
process:

1. Starts normally, loads standard DLLs (ntdll, kernel32, kernelbase, bcrypt,

bcryptprimitives, netapi32, samcli, FWPUCLNT.DLL, rpcrt4, ws2_32, msvcrt, etc.)

1. Reads locale/NLS registry settings
2. Initializes the WinSock2 protocol catalog (standard WSAStartup registry reads)
3. Does a handful of CreateFile calls on C:\, C:\Windows, C:\Windows\System32, and

files under its own downloads folder

1. Then goes completely silent — no further Registry, File System, or Network

operations of any kind for the remainder of the capture (confirmed 20+ seconds
idle in the capture; the live process was left running for many minutes/hours
with no change observed live via Process Hacker)

1. One thread remains alive (never exits) while the process is "hung"

Critically: no TCP/UDP/DNS events are ever emitted, meaning the process hangs
before attempting any network connection — this rules out any network/TLS/firewall/
proxy/DNS explanation and points to an internal deadlock or infinite wait (e.g. on a
synchronization primitive) inside the binary itself.

Attachments

• Full Process Monitor .PML trace: [attach the file here]

Logfile.zip

• Process memory dump of the hung claude-2.1.259-win32-x64.exe: https://drive.google.com/file/d/1rIK5oZ9WV-M8FlKwmGvVYDoAt2-4FjZh/view?usp=sharing

Happy to provide any additional diagnostics needed.

<!-- Failed to upload "claude-2.1.259-win32-x64.exe.dmp" -->

<!-- Failed to upload "claude-2.1.259-win32-x64.exe.dmp" -->

<!-- Failed to upload "claude-2.1.259-win32-x64.zip" -->

<!-- Failed to upload "claude-2.1.259-win32-x64.zip" -->

What Should Happen?

Running claude should start the interactive Claude Code session (or, on first
run, guide the user through login) within a few seconds. Running the installer
(irm https://claude.ai/install.ps1 | iex) should complete the "Setting up
Claude Code..." step and finish successfully, leaving a working claude.exe at
~/.local/bin.

Instead, both hang indefinitely (left running for hours with no change) with no
error, no output, and no network activity at all (confirmed via Process Monitor
— see details below).

Error Messages/Logs

Steps to Reproduce

1. On a Windows 10 (build 19041) domain-joined machine, open PowerShell (reproduced

in both Windows PowerShell 5.1 and cmd.exe).

1. Run the native installer:

irm https://claude.ai/install.ps1 | iex

1. Observe: the installer prints "Setting up Claude Code..." and never progresses

further, even after leaving it running for hours.

(This step internally spawns <downloads>\claude-2.1.259-win32-x64.exe install
latest — this child process is the one that actually hangs; confirmed with
Process Monitor, see attached .PML.)

Alternatively, once any working claude.exe is present at ~/.local/bin/claude.exe:

1. Open a fresh PowerShell or cmd.exe window.
2. Run: claude
3. Observe: nothing happens, the terminal just sits there indefinitely.
4. For comparison, run: claude --version and claude --help

-> both return instantly and correctly (e.g. "2.1.259 (Claude Code)"), showing
the binary itself is not corrupted and basic startup/argument parsing works.
Only the interactive/install code path hangs.

No special project, repo, or config is needed to reproduce — this happens in a
brand-new user profile with ~/.claude fully removed, and also after completely
uninstalling the Claude Desktop app, ruling those out as contributing factors.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.259 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_