CLI hangs indefinitely on every subcommand except --version (headless Linux, both native and npm installs)

Bug report draft — Claude Code CLI hangs on every subcommand except --version (headless Linux)

Summary

On a headless Ubuntu/Debian-family Linux host, every claude CLI invocation except --version hangs indefinitely (observed up to 300s+, killed by external timeout) with zero stdout/stderr output, even when run in a genuine interactive TTY by a human. Strace shows multiple threads spinning at ~100% CPU each, dominated by tight pread64() loops against a /proc-style stat file, interleaved with heavy futex/madvise activity — no blocking syscall, no network I/O wait. This matches the pattern in #18280, #34518, #10493, #19393, but those describe idle-after-some-time CPU drift; this report is every invocation hanging immediately, including first-run and non-interactive automation.

Environment

• OS: Linux (headless server, no desktop environment)
• Claude Code versions reproduced: 2.1.232 (native installer, ~/.local/bin/claude) and 2.1.233 → 2.1.251 (npm global via nvm, Node v22.23.2)
• Two parallel install methods present: native installer (curl -fsSL https://claude.ai/install.sh | bash) and npm install -g @anthropic-ai/claude-code. Both affected.

Steps to reproduce

1. Fresh/existing ~/.claude state (reproduced both with an empty ~/.claude and one accumulated over prior use).
2. Run claude --help, claude auth status --json, or bare claude (no args), from a real interactive SSH terminal.
3. Observe: no output at all (not even a login URL, theme prompt, or error) for the full observation window (tested up to 300s).
4. claude --version (only) returns immediately and correctly.

What we ruled out

• Not a TTY issue: reproduces identically in a genuine interactive terminal, not just non-interactive/scripted invocation.
• Not network-blocked: curl https://api.anthropic.com from the same host returns in ~0.12s.
• Not disk/inode exhaustion: host at 8% disk usage, 6% inode usage.
• Not the background auto-updater: DISABLE_AUTOUPDATER=1 set for the invocation, hang reproduces identically (3/3 attempts).
• Not version-specific: reproduces on 2.1.232 and, intermittently, on 2.1.251 after npm update -g.
• Not fixed by reinstalling: re-running the official install script is a silent no-op on an existing native install (binary mtime unchanged, no error).

Process/strace evidence

ps aux during a hang shows the process in R/running state (not S/sleeping — i.e., actively consuming CPU, not blocked waiting on I/O), with two instances left running unattended for 11 days at ~100% CPU each before being noticed and killed.

Tail of strace -f -tt on a hung claude --help (thread IDs are Node worker threads):

374996 pread64(6,  <unfinished ...>
374996 <... pread64 resumed>"1446252 78638 58428 15191 0 1391"..., 256, 0) = 38
374996 pread64(6, "1446252 78802 58428 15191 0 1391"..., 256, 0) = 38
374996 pread64(6, "1446252 78881 58428 15191 0 1391"..., 256, 0) = 38
[... same fd read repeatedly within single-digit milliseconds, second field monotonically increasing ...]
375001 futex(0x265cf300454, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ...) <unfinished ...>
375002 futex(...) = -1 ETIMEDOUT
[... repeated futex wait/wake/timeout across ~8 threads, no forward progress ...]

The read pattern ("1446252 78638 58428 15191 0 1391...") matches the shape of a /proc/[pid]/stat or /proc/self/statm-style file, read via pread64 on a fixed fd (fd 6) hundreds of times per second rather than on any reasonable polling interval.

Impact

Any headless/automated usage of the CLI (CI, server-side agent orchestration, systemd services) is non-functional on this host across multiple recent versions and both install methods. This blocks server-side agent pipelines that shell out to claude --print non-interactively.

Request

• Is this the same root cause as #18280 / #34518 / #10493 / #19393, or a distinct immediate-hang variant?
• Any known fix version or workaround beyond what we already ruled out above?