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

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 --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 ` 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
...`). 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 ` 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

```shell

```

### 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 ` install` internally.
4. 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.
5. Running the already-downloaded binary directly reproduces it in isolation:
`~/.claude/downloads/claude--linux-x64 install` hangs the same
way, as does `install --help` (i.e. it hangs before doing any real
installation work).
6. `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_

Start by reproducing the hang with the standalone binary's install --help and doctor commands on the described Ubuntu 24.04 Proxmox/QEMU VM, then attach strace and inspect the repeated /proc/stat pread64 calls. Compare these paths with --version and --print, which work normally. Done means install and doctor complete without an infinite CPU spin, or stop with a diagnostic timeout and error.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.