[BUG] v2.1.248 hangs indefinitely on startup on Windows 11 VM (works on 2.1.58)

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

Claude Code v2.1.248 hangs indefinitely on startup on Windows 11 (running as a VM), before login, before any network activity, and before any debug/log output — for every invocation except --version. Downgrading to v2.1.58 (via WinGet) resolves the issue completely on the identical machine.

Environment

• OS: Windows 11 22H2 (build22621.4317) (virtual machine — hypervisor/host: Proxmox
• RAM: 16 GB
• Claude Code version (broken): 2.1.248
• Claude Code version (working): 2.1.58
• Install method: WinGet (winget install Anthropic.ClaudeCode)
• Shell tested: PowerShell (also reproduced with --debug flag)

Symptom

claude --version returns instantly and correctly (2.1.248 (Claude Code)).

Every other invocation hangs indefinitely with no output at all:

• claude (interactive)
• claude -p "hello"
• claude --debug -p "hello"

No browser ever opens. No file is ever created under %USERPROFILE%\.claude\ — no .credentials.json, and no debug log under %USERPROFILE%\.claude\debug\, even after multiple multi-minute hangs. This is a fresh install with no prior login state.

Diagnostic steps taken (in order), each ruling out a cause

1. Network reachability — Test-NetConnection to the API host succeeds. curl.exe -v https://api.anthropic.com returns a fast HTTP/1.1 404 (expected for the bare root). Network path to Anthropic's API is fine.
2. IPv6 / dual-stack DNS — Process Monitor showed a repeating "Thread Exit" pattern (3–4 threads cycling) on claude.exe while CPU sat around 25%. Suspected IPv6 fallback retry loop. Tested:

• NODE_OPTIONS="--dns-result-order=ipv4first" — no change.
• Fully disabled IPv6 on the network adapter + rebooted — no change (same Thread Exit pattern still occurs).
• Ruled out as the cause.

1. Browser-launch mechanism — start https://claude.ai from the same shell opens Chrome normally and auto-logs in via existing session. Browser launch is not the blocker; claude never even attempts to open a browser.
2. Credential/auth state — no .credentials.json ever gets created, at any point across all attempts, ruling out a stale/corrupt credential file.
3. Live process inspection — netstat -ano filtered to the claude.exe PID during an active hang shows zero connections, zero listeners — confirms the process is not making or waiting on any network I/O while hung.
4. Process Explorer thread stack — the busy thread's call stack resolves to deep inside V8 internals: claude.exe!v8::internal::Internals::GetCurrentIsolate+0x15bdfce (note the enormous offset — no usable symbols are available for this binary, so the specific function name is not meaningful, but landing inside V8 rather than an OS wait/syscall function indicates the thread is actively executing JIT-compiled JavaScript in a tight loop, not blocked on I/O).
5. Memory — 16 GB total, no evidence of paging/swapping in Process Monitor, single-process CPU usage isolated to ~25% — memory pressure ruled out.
6. Version bisection — downgraded via winget install Anthropic.ClaudeCode --version 2.1.58 --force. v2.1.58 works normally: login flow triggers, browser opens as expected, -p mode responds.

Separately noted (possibly unrelated)

irm https://claude.ai/install.ps1 | iex has never worked on this VM (this is why WinGet was used for the original install). Manually downloading with curl.exe -v https://claude.ai/install.ps1 -o install.ps1 returns an HTTP response but an empty file — suspected to be a corporate network security proxy filtering .ps1/script-type content specifically, since plain binary/API requests to the same domain succeed. Flagging in case it's relevant, but this looks like a separate, network-policy-level issue rather than the same bug as the v2.1.248 hang (the hang above shows zero network activity, whereas this is clearly network-layer interception).

Conclusion / ask

This looks like a genuine regression introduced somewhere between v2.1.58 and v2.1.248 that causes an infinite loop very early in startup (before auth, before network, before logging init) under some condition specific to this Windows VM environment. Given the V8-internal spin with no I/O, it may be a busy-wait/infinite-loop bug in a startup code path (e.g., locale detection, terminal capability probing, or similar environment-detection logic) that behaves differently in this VM than on the reporter's other (working) machines.

What Should Happen?

claude -p "Hall" should just return

Error Messages/Logs

Steps to Reproduce

See above

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

It worked in 2.1.58

Claude Code Version

2.1.248

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_