[BUG] Claude Code CLI native binary spins at ~100% CPU indefinitely on startup (VS Code Remote-SSH, Ubuntu 26.04)

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 1 comment · opened Aug 18, 2026

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?

Summary

Claude Code CLI native binary (v2.1.234) hangs indefinitely and pins one CPU core to ~99.9% on every invocation — both claude auth status --json (spawned by the VS Code extension) and interactive claude (run manually in terminal) — on a specific remote Ubuntu 26.04 LTS VM. The VS Code "Claude Code for VS Code" extension consistently fails with:

Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

Environment

  • OS: Ubuntu 26.04 LTS (Resolute Raccoon), kernel 7.0.0-29-generic
  • CPU: 4 cores, full virtualization, tsc + constant_tsc present (no TSC reliability issue)
  • RAM: 7.8Gi total, 3.7Gi free at time of testing
  • Disk: 96G volume, 83G free
  • Access method: VS Code Remote-SSH
  • Extension: anthropic.claude-code v2.1.234
  • Both the extension-bundled native binary (resources/native-binary/claude) and an independently npm install -g @anthropic-ai/claude-code-installed CLI exhibit identical hanging/spinning behavior (the npm package appears to fetch/run the same current native binary regardless of pinned npm version, so testing older npm versions did not produce a different binary).

What's been ruled out

  • Network: curl to api.anthropic.com succeeds normally (HTTP/2, valid cert, expected 404 on GET /). curl to claude.ai returns a Cloudflare bot-challenge (403, "Just a moment..."), but this does not appear to be the cause of the hang (see below).
  • DNS: resolves fine for both domains.
  • Disk/RAM: plenty of free space and memory; no swap pressure.
  • ~/.claude/projects session bloat: directory doesn't even exist — ruled out.
  • OS/kernel version: already on latest Ubuntu LTS (26.04); no upgrade path available.
  • TSC/virtualization timing: tsc and constant_tsc CPU flags are present.
  • Sanctions/region block: api.anthropic.com responds with a normal API response, not a region-restriction message.
  • Distribution channel: native binary bundled in VS Code extension and CLI installed via npm install -g @anthropic-ai/claude-code (including pinning old versions like 1.0.0) show the same behavior and the same reported version (2.1.234) at runtime — suggesting all channels converge on fetching/running the same current native binary.

Diagnostic evidence

ps aux during a hang shows the process pinned at ~99.9% CPU, state Rl (running, multi-threaded), for extended periods (one instance ran 20+ minutes before being killed).

strace -f -e trace=connect,network on the hung process shows zero network syscalls — ruling out a network-level explanation for the hang itself.

strace -f -tt -o (writing directly to a file to avoid pipe-buffering artifacts) on the hung process shows a tight repeating loop across two threads:

  • Thread A: repeated mprotect(), pread64(fd, "<changing integer fields>", 256, 0) (reading from a /proc-style pseudo-file at offset 0 each time, with fluctuating numeric fields resembling CPU/jiffie counters), and dozens of madvise(..., MADV_DONTNEED) calls per burst (releasing memory pages) — a pattern strongly resembling a JS-engine garbage collector (V8/Bun) running continuously.
  • Thread B: futex(..., FUTEX_WAIT_PRIVATE, ..., {tv_sec=30, ...}) repeatedly timing out with ETIMEDOUT, then re-waiting with a short (~98ms) timeout — consistent with a periodic health-check/heartbeat thread.

This pattern (self CPU-time polling + continuous madvise/mprotect activity) suggests the runtime's GC pacing or self-throttling heuristic is reading its own CPU usage and reacting by triggering more GC work, which increases CPU usage further, creating a feedback loop that never resolves — possibly triggered by an interaction with this VM's virtualization environment, though the exact trigger is unconfirmed.

Attempted fixes (none resolved it durably)

  1. Reinstalling via official curl -fsSL https://claude.ai/install.sh | bash (worked once the piped-stdin issue was worked around by downloading then running the script directly).
  2. Reinstalling via npm install -g @anthropic-ai/claude-code (including pinned old versions) — same behavior, same runtime-reported version.
  3. Disabling extension auto-update — appeared to resolve it once, but the hang recurred on the next real session; the extension continued spawning the same v2.1.234 native binary regardless.
  4. Enabling the VS Code setting "Claude Code: Use Terminal" — extension host logs still show Spawning Claude with SDK query function afterward (setting may not have been picked up without a full VS Code restart, or does not affect this code path).
  5. Killing all stray/runaway claude processes and retrying clean — hang recurs on next invocation.

Request

Would appreciate guidance on:

  • Whether this is a known issue with the native binary's GC/runtime under certain virtualization configurations.
  • Whether there's a way to force a specific (older, unaffected) native binary version rather than always fetching the latest.
  • Whether there's a debug/verbose flag that produces meaningful output even during this spin state (our --debug runs produced empty log files).

What Should Happen?

q

Error Messages/Logs

Steps to Reproduce

q

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

last

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗