[BUG] claude --version hangs at 99% CPU, regression between 2.1.112 and 2.1.113

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?

Bug: claude --version (and any invocation) hangs at ~99% CPU on first run, regression between 2.1.112 and 2.1.113
Summary
On a fresh install with no prior ~/.claude state, invoking the native claude binary hangs indefinitely — no output, no error, ~99% CPU on a single core — starting with version 2.1.113. Version 2.1.112 and earlier work correctly. Confirmed via full bisection across 259 published versions between 2.0.0 and 2.1.220.
Environment
OS: Debian GNU/Linux 13 (trixie)
Kernel: 6.12.100+deb13-amd64
Virtualization: KVM (full VM, not a container)
CPU: 2 vCPU
RAM: 1.9 GiB total, ~1.4 GiB free at time of testing
Node.js: v24.18.1
Install method: npm install -g @anthropic-ai/claude-code
Fresh account: no ~/.claude directory, no ~/.claude.json, no prior sessions existed before first invocation
Steps to reproduce
On the environment above, npm install -g @anthropic-ai/claude-code@2.1.220 (or any version ≥2.1.113)
Run claude --version
Process hangs indefinitely instead of printing the version and exiting
Expected behavior
claude --version should print the version string and exit immediately (as it does on 2.1.112 and earlier).
Actual behavior
No output at all (not even partial)
Process state R (running, not blocked/waiting — confirmed via /proc/<pid>/status)
wchan = 0 (not blocked on any kernel wait function — this is a userspace busy-loop, not I/O wait)
CPU usage ~99% on one core, sustained (observed for 2+ minutes before being killed)
Does not respond to SIGTERM; requires kill -9
Open file descriptors at time of hang: stdin→/dev/null, stdout/stderr→log file, one eventpoll fd, one eventfd, /dev/urandom, and — notably — an open, actively-read fd to /proc/<own-pid>/statm (the process's own memory-statistics file), suggesting a self-monitoring/resource-check loop that is spinning without a proper sleep/backoff, or failing its exit condition and retrying continuously.
Ruled out during investigation (none of these were the cause)
Disk space (35% used, 11 GiB free)
Locale/charset (en_US.UTF-8, properly generated, present in locale -a)
Missing shared libraries (ldd resolves everything cleanly against a non-truncated, correctly-sized binary)
cgroup v2 memory controller availability (memory.max/memory.current present and correct at the process's actual cgroup path, /user.slice/user-.slice/session-.scope/)
Environment variables (hangs identically under env -i with a fully stripped environment)
Native binary vs. the JS fallback launcher (cli-wrapper.cjs) — both hang identically, since the wrapper just spawnSyncs the same native binary
Version-specific fluke — reproduced independently on both 2.1.210 and 2.1.220
Bisection result
Binary search across all 259 published versions in the 2.0.x–2.1.x range:
2.1.112 → works (instant 2.1.112 (Claude Code) output, exit 0)
2.1.113 → hangs (timeout/exit 124, 99% CPU)
All versions ≥2.1.113 tested during bisection (2.1.113, 2.1.116, 2.1.124, 2.1.145, 2.1.210, 2.1.220) hang identically. All versions ≤2.1.112 tested (1.0.0, 2.0.0, 2.1.67, 2.1.107, 2.1.111, 2.1.112) work correctly.
Workaround
Pin to 2.1.112 and disable auto-updates to prevent silent regression:
Bash
Then set "autoUpdates": false in ~/.claude.json.
Possibly related existing issues
Found via search, none appear to be an exact match for this specific trigger (hangs on bare --version on a completely fresh install, before any session/config exists), but share the same CPU-spin/eventpoll/unresponsive-to-SIGTERM signature:
anthropics/claude-code#22158 — "v2.1.27 hangs at 100% CPU after first response (v2.1.25 works)"
anthropics/claude-code#22041 — "CLI hangs at 99% CPU on startup with large session .jsonl files"
anthropics/claude-code#22240 — "Claude Code process hangs with 100% CPU usage (requires kill -9)" (macOS/ARM64, different trigger — after API request, not on fresh first run)
This report's reproduction differs from all of the above in that it happens on --version alone, on the very first invocation, with zero pre-existing ~/.claude state — so it may be a distinct root cause that happens to share the same failure signature (a busy-poll loop somewhere in early startup/self-check code).

What Should Happen?

Claude should start

Error Messages/Logs

Steps to Reproduce

See other field. Created by Claude code session from different host.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.113

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

iTerm2

Additional Information

_No response_