[BUG] Native Windows claude.exe hangs indefinitely on any invocation (--version/--help/bare) starting somewhere after 2.1.58 — works fine on 2.1.58, confirmed regression

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest match is #76329, but that report shows near-zero CPU usage during the hang and explicitly states "not a regression, never worked" — this report is a confirmed regression with sustained CPU usage during the hang, so it looks like a distinct root cause despite the similar surface symptom)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

The native Windows claude.exe binary hangs indefinitely on any invocation — --version, --help, and bare invocation with no arguments all hang identically, producing zero output (confirmed via output redirected to a file, which stayed at 0 bytes) despite Task Manager showing the process actively consuming ~26% CPU (not idle/blocked on I/O).

Critically: downgrading to 2.1.58 resolves the issue completely — the binary launches and responds normally. This confirms it's a regression introduced sometime after 2.1.58, not an environment-wide execution problem.

What Should Happen?

claude --version (or --help, or bare claude) should return output within a second or two, as it does on 2.1.58.

Steps to Reproduce

1. On the affected Windows machine, install via the native installer targeting latest (currently resolves to 2.1.220): irm https://claude.ai/install.ps1 | iex
2. Run claude --version — hangs indefinitely, zero output, no exit
3. Also reproduced identically with claude --help and bare claude (no args) — all hang the same way before reaching argument-specific logic
4. Reinstall pinned to 2.1.58: & ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.58 — binary launches and responds normally

Diagnostic steps already ruling out other causes

• Network connectivity confirmed fine and fast: Test-NetConnection to both claude.ai and downloads.claude.ai succeed; manually replicating the installer's own Invoke-RestMethod/Invoke-WebRequest calls (version lookup, manifest, binary download) all complete in well under a second
• Not Windows Defender: no elevated CPU on MsMpEng.exe during the hang
• Not a third-party EDR: checked for CrowdStrike/SentinelOne/CarbonBlack/Cylance/Cortex XDR/Tanium process names, none present
• Not Mark-of-the-Web/SmartScreen: Unblock-File on the downloaded binary before execution made no difference
• Not a stale/locked process: Get-Process for the binary's process name found nothing running before each fresh attempt
• General process execution in the VM is unaffected: Start-Process cmd.exe /c echo hello returns in ~50ms while the same VM hangs on claude.exe
• Reproduced identically over both a noVNC console session and RDP to the same VM, ruling out display-protocol overhead

Is this a regression?

Yes

Last Working Version

2.1.58

Claude Code Version

2.1.220 (latest as of testing; hangs). 2.1.58 confirmed working.

Platform

Claude subscription (Pro/Max/Team) — OAuth login

Operating System

Windows (native install, not WSL)

Terminal/Shell

PowerShell 7.6.3

Additional Information

Reproduced on a QEMU-virtualized Windows 11 VM (nested: physical host → browser-based noVNC/RDP → QEMU guest). Given the confirmed 2.1.58-vs-latest regression and active (non-idle) CPU usage during the hang, this looks like a genuine code regression in a startup routine (e.g. a CPU-feature-detection or timing-calibration path) rather than an environment-specific execution block — happy to gather more diagnostics (Process Monitor/Process Explorer thread stacks, bisection across specific versions between 2.1.58 and 2.1.220) if useful.