[BUG] claude install and claude doctor hang indefinitely at ~100% CPU (Proxmox/QEMU VM)

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 install and claude doctor hang indefinitely at ~100% CPU on a specific Proxmox/QEMU VM

Summary

On a specific Ubuntu 24.04 VM (Proxmox/QEMU KVM guest), both claude install
(the setup step the native installer runs automatically) and claude doctor
hang indefinitely, pinning one CPU core at ~100%, with no forward progress
and no output. Every other command tested — claude --version, claude
--print, full interactive claude sessions, claude mcp login, claude
remote-control — works correctly and quickly on the same install. This is
narrowly scoped to these two subcommands.

Environment

• Claude Code version: 2.1.245 (native/standalone installer, Linux x64 binary)
• OS: Ubuntu 24.04.4 LTS (stock noble-server-cloudimg-amd64 cloud image)
• Virtualization: QEMU/KVM guest under Proxmox VE 9.2.4
• CPU model tested: both Proxmox's default kvm64 baseline and host

passthrough — hang reproduces identically under both, so it is not a
missing-CPU-feature issue

• 4 vCPU / 4096MB RAM (later 6144MB — memory was not the limiting factor;

free/available had comfortable headroom throughout)

• No swap configured
• Install method: curl -fsSL https://claude.ai/install.sh | bash

What does not reproduce it

• claude --version — returns instantly, every time.
• claude --print "..." — works correctly and quickly, including when not

yet authenticated (correctly reports "Not logged in").

• Full interactive claude session, including workspace-trust dialog and

/login OAuth flow — all work normally.

• claude mcp login <server> --no-browser — works.
• claude remote-control — works (interactive prompts and all).

So this is not a general runtime failure, not an auth issue, not a
networking issue (see below), and not specific to non-interactive/no-TTY
invocation (tested both with and without a real pty allocated).

Diagnosis performed

• Not a hang on I/O or a specific syscall. strace -p <pid> attached to

a live hang shows continuous activity, not a blocked read/poll/futex-wait:
a tight loop of futex(..., FUTEX_WAKE_PRIVATE, ...), sched_yield(),
and repeated pread64(fd, "1427902 29628 23313 15192 0 1405...", 256, 0)
calls at sub-millisecond intervals with no backoff. The pread64 payload
matches the /proc/stat CPU-time-counters format (cpu <user> <nice>
<system> <idle> ...). This looks like a runtime timer/clock-calibration
loop (possibly Bun's, since Claude Code bundles a Bun runtime) that is
repeatedly re-sampling system CPU counters and never reaching whatever
convergence condition it's waiting for, rather than genuinely blocking on
anything external.

• Not a network/DNS issue. While a doctor process was hung, ss -tnp

showed zero open network connections for that PID — it wasn't waiting on
any socket. (Separately confirmed general network health was fine: both
IPv4 and IPv6 connectivity to api.anthropic.com worked correctly via
curl throughout.)

• Not a CPU-feature-detection issue. Reproduced identically on Proxmox's

default minimal kvm64 CPU model and after switching to full host
passthrough (a cold VM restart to apply). No change in behavior either way.

• Not a memory-pressure issue. free showed healthy available memory

(multiple GB) at the time of each hang; the installer's own low-memory
warning path checks for <512MB, which was never close to being hit.

• Not TTY/pty-detection. Reproduced identically whether invoked via a

plain SSH command (no pty), via ssh -tt (pty allocated), and with stdin
explicitly redirected from /dev/null.

Workaround in use

Skip the native installer's install step; instead let install.sh
download and checksum-verify the binary as normal, then copy it directly to
~/.local/bin/claude (already on PATH via Ubuntu's default .profile)
rather than invoking <binary> install. This produces a fully working
claude CLI. claude doctor is simply never run on this VM.

Impact

Low for experienced users who can work around it as above, but the failure
mode itself is bad: no error message, no timeout, indefinite 100% CPU
consumption, and it's the very first thing install.sh runs — so a
first-time user on an affected environment sees the installer hang forever
with zero diagnostic signal.

Suggested starting points for investigating upstream

• Whatever code path install/doctor take that plain command execution

(--version, --print) doesn't — they likely share some
environment-probing or self-update-check logic that the fast paths skip.

• The repeated /proc/stat-shaped pread64 calls strongly suggest a timer

or CPU-usage calibration loop (possibly in the bundled Bun runtime) with a
convergence/exit condition that isn't being met in this specific
virtualized environment — worth checking whether it's polling for CPU
idle, benchmarking clock resolution, or similar, and whether it has any
iteration cap or timeout at all.

What Should Happen?

claude install should complete the setup step (create the launcher symlink / shell integration) and exit in well under a second. claude doctor should run its diagnostic checks and print the results. Neither should hang indefinitely, consume 100% CPU with no forward progress, or produce zero output — at minimum there should be a timeout with an error message rather than a silent infinite spin.

Error Messages/Logs

Steps to Reproduce

1. Provision a fresh Ubuntu 24.04 cloud-init VM (no prior Claude Code state).
2. curl -fsSL https://claude.ai/install.sh | bash
3. The installer downloads and verifies the binary successfully, prints

Setting up Claude Code..., then invokes <binary> install internally.

1. This hangs forever. No output, no error, no timeout — confirmed hung for

over 22 minutes of continuous 99.9% single-core CPU usage before being
killed.

1. Running the already-downloaded binary directly reproduces it in isolation:

~/.claude/downloads/claude-<version>-linux-x64 install hangs the same
way, as does install --help (i.e. it hangs before doing any real
installation work).

1. claude doctor (run after manually placing the binary on PATH to work

around the install hang) reproduces the identical symptom.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.245

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_