[BUG] Claude Code v2.1.27 freezes with 100% CPU on Synology NAS (Linux 4.4 kernel) — v2.1.25 works fine
Bug Description
Claude Code v2.1.27 freezes with 100% CPU usage on Synology NAS immediately after the user sends any message. The REPL mounts successfully and the prompt appears, but upon submitting any input (even a simple "hi"), the process enters a CPU-bound infinite loop and becomes completely unresponsive.
v2.1.23 and v2.1.25 work perfectly on the same system. Only v2.1.27 exhibits this behavior.
Environment
- Platform: Synology NAS, DSM 7.3.2
- Kernel: Linux 4.4.302+ (SMP, x86_64)
- CPU: Intel Celeron J4125 @ 2.00GHz (4 cores)
- RAM: 17GB
- glibc: 2.36
- Claude Code: v2.1.27 (also tested v2.1.23 and v2.1.25)
- Installation: Native installer (
curl -fsSL https://claude.ai/install.sh | sh)
Steps to Reproduce
- Install Claude Code v2.1.27 on a Synology NAS (DSM 7.x, Linux 4.4 kernel)
- Run
claudefrom terminal (SSH) - Wait for the REPL prompt to appear (startup completes successfully)
- Type any message (e.g., "hi") and press Enter
- The process immediately jumps to ~95-100% CPU and becomes unresponsive
- No output is produced; the terminal is frozen
kill -9is required to terminate the process
Non-interactive mode also freezes:
claude -p "say hello" # Hangs at 100% CPU, never returns
Expected Behavior
Claude Code should process the message and return a response, as it does with v2.1.23 and v2.1.25.
Actual Behavior
Process enters a CPU-bound loop (State: R, ~100% CPU) and never produces output. Debug log shows startup completes normally but no entries appear after the user submits a message.
Process state during freeze (/proc/<pid>/status):
State: R (running)
VmSize: 74692796 kB
VmRSS: 445100 kB
Threads: 8
voluntary_ctxt_switches: 985
nonvoluntary_ctxt_switches: 5612
The high ratio of nonvoluntary to voluntary context switches confirms the process is CPU-bound (spinning), not waiting on I/O.
Version Comparison
| Version | Result |
|---------|--------|
| v2.1.23 | Works — responds instantly |
| v2.1.25 | Works — responds instantly |
| v2.1.27 | Freezes — 100% CPU, no response |
Tested with identical settings, same system, same terminal session:
~/.local/share/claude/versions/2.1.23 -p "say hello" # ✅ Returns immediately
~/.local/share/claude/versions/2.1.25 -p "say hello" # ✅ Returns immediately
~/.local/share/claude/versions/2.1.27 -p "say hello" # ❌ 100% CPU, never returns
Debug Log (v2.1.27)
Startup completes without errors:
[STARTUP] setup() completed in 35ms
[STARTUP] Commands and agents loaded in 9ms
[STARTUP] showSetupScreens() completed in 441ms
[STARTUP] MCP configs loaded in 478ms
Ripgrep first use test: PASSED (mode=system, path=rg)
[REPL:mount] REPL mounted, disabled=false
AutoUpdaterWrapper: Installation type: native
Checking for native installer update to version 2.1.27
Found 2.1.27 at .../claude, skipping install
No further log entries appear after user input — the freeze occurs silently.
Additional Notes
- Workaround: Downgrade to v2.1.25 by relinking
~/.local/bin/claude→~/.local/share/claude/versions/2.1.25 - Auto-update disabled via
DISABLE_AUTOUPDATER=1env to prevent regression - A secondary issue was also found: the built-in ripgrep binary fails on this kernel (
Ripgrep first use test: FAILED), resolved by settingUSE_BUILTIN_RIPGREP=0. However, this is separate from the v2.1.27 freeze — the freeze occurs even after ripgrep is working correctly. - The same NAS hardware runs Claude Code successfully inside a Docker container (code-server), suggesting the issue is specific to the native binary on the Linux 4.4 kernel.
Possibly Related Issues
- #19393 — High CPU usage (100%+) when idle (v2.1.12)
- #18532 — Complete Freeze 100% CPU (v2.1.9, macOS ARM64)
- #13161 — ripgrep failure on FreeBSD (non-standard kernel)
This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗