[BUG] Claude Code install/launch hangs indefinitely on Hyper-V VM with Processor Compatibility Mode enabled

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?

Claude Code's Linux native binary and Debian package both livelock — pin one CPU core at 100%, produce no output, and do not respond to SIGINT cleanly on Ubuntu Server 26.04 LTS VMs where the Hyper-V host has "Processor Compatibility Mode" enabled for that VM — the CPU-feature-masking option that allows live migration across a pool of mixed CPU generations. Affects both install and interactive claude launch.

What Should Happen?

Installs and launches normally.

Error Messages/Logs

[main thread] resolves cwd via getcwd()/openat()/readlink() on $HOME
[main thread] futex(..., FUTEX_WAKE_PRIVATE, 1) = 1
[main thread] <no further syscalls for remainder of hang>

[worker thread A] futex(..., FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ...) = -1 ETIMEDOUT (~10s cycle)
[worker thread B] futex(..., FUTEX_WAIT_PRIVATE, 0, {tv_sec=30}) = -1 ETIMEDOUT (~30s cycle, exits cleanly on its own)

Threads:   4 total,   1 running,   3 sleeping,   0 stopped,   0 zombie
%Cpu(s): 30.0 us,  0.0 sy,  0.0 ni, 70.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7332.8 total,   5539.5 free,    753.0 used,   1294.5 buff/cache
MiB Swap:   4096.0 total,   4096.0 free,      0.0 used.   6579.8 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2100 test      20   0 5566144  84216  58004 R  99.9   1.1  33:10.80 claude
   2102 test      20   0 5566144  84216  58004 S   0.0   1.1   0:00.00 mi-scavenger
   2104 test      20   0 5566144  84216  58004 S   0.0   1.1   0:00.00 Bun Pool 0
   2105 test      20   0 5566144  84216  58004 S   0.0   1.1   0:00.00 Bun Pool 1

Confirmed via strace, component isolation, and cross-environment testing:

- EDR (SentinelOne) — fully disabled, no change
- Local filesystem — confirmed local disk, not a network mount
- Stale lockfiles / orphaned processes — killed and retried clean, no change
- Guest kernel version — upgraded, no change
- Network — traced with `strace -f -yy`; zero `socket()`/`connect()`/ `getaddrinfo()` calls occur before or during the hang
- D-Bus / session keyring — tested under `dbus-run-session`, no change
- stdin/tty — confirmed attached to a real pty, not a pipe; not blocked waiting on input
- VM generation — confirmed Gen 2 (UEFI, Secure Boot enabled) on both a hanging and a working VM

Steps to Reproduce

Disabling Processor Compatibility Mode on the affected VM resolves the hang completely — both install and claude succeed immediately afterward, no other change made. Re-enabling it reproduces the hang again.

Confirmed on two separate VMs in the same cluster: the original (pre-existing) VM, and a freshly-built VM on the same host/storage/network — both hang with Compatibility Mode on, both work with it off. This isolates the variable to that one processor setting, not the host, cluster storage, network config, or guest OS build.

Negative control: OpenAI's Codex CLI (native Rust binary, non-Bun/Node runtime) launches successfully on the same affected VM with Compatibility Mode still enabled. Suggests this is specific to something in Claude Code's runtime (Bun), not a kernel- or hypervisor-wide effect on all native binaries.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.267 (apt) and 2.1.280 (native installer) — both hang identically

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

CPU feature comparison (three states)

Compatibility Mode off, clustered (works):
rdtscp ssse3 sse4_1 sse4_2 popcnt movbe fma pcid xsave avx f16c bmi1
avx2 smep bmi2 erms invpcid xsaveopt pdpe1gb [full set, native baseline]

Compatibility Mode on, standalone host (works):
rdtscp ssse3 sse4_1 sse4_2 popcnt [present]
avx/avx2/fma/pcid/etc. [absent — same as clustered-on below]

Compatibility Mode on, clustered host (hangs):
rdtscp ssse3 sse4_1 sse4_2 popcnt [absent]
avx/avx2/fma/pcid/etc. [absent — same as standalone-on above]

The clustered and standalone Compatibility Mode profiles both mask avx/avx2 and similar — that's common to both the working and failing case, so it isn't the trigger. The only flags present when it works and absent when it hangs are: rdtscp, ssse3, sse4_1, sse4_2, popcnt.

Why the mask differs between hosts with the same setting enabled

Confirmed via Get-VM | Select ConfigurationVersion: the affected Hyper-V 2019 host caps VM Configuration Version at 9.0; the working Hyper-V 2022 host runs 10.0. Compatibility Mode's masked baseline is tied to Configuration Version, which is capped by host Hyper-V build version, not something a VM or its placement can override. This explains why the failure tracks the host's Hyper-V version rather than clustering itself — clustering only appeared relevant because the one 2019 host available happens to be the only clustered one. A fresh VM built directly on the affected 2019 cluster reproduces the hang identically to the original, ruling out one-off VM configuration drift as the cause.

This is a livelock, not a blocked wait

top -H on a hung process shows the main thread pinned at ~99–100% of one core continuously (confirmed over 30+ minutes of accumulated CPU time), while all other threads (mi-scavenger, two Bun Pool workers) sit at 0% CPU, correctly parked on futex() waits.

strace -f -p <main thread PID> attached to the live hang shows zero syscalls from the main thread for the entire observation window — no futex, no poll, nothing the kernel can see or use to wake it. The other three threads in the process continue their normal periodic futex wait/timeout cycle throughout, undisturbed. This isolates the defect to a pure userspace spin loop on the main thread specifically — not a blocked/sleeping wait, and not a pool-wide runtime deadlock.

Independently reproduced by a second party (OpenAI Codex CLI session, same VM, separate SSH session, same cluster) via claude --help, also observing sustained ~100% single-core usage with no output.