[BUG] claude -p (headless mode) hangs indefinitely with zero output on ARM64 Linux (Synology NAS), across multiple CLI versions
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?
claude -p (headless mode) hangs indefinitely with zero output on ARM64 Linux (Synology NAS), across multiple CLI versions
Environment
Platform: Docker container (python:3.11-slim base image) running on a Synology NAS
Architecture: aarch64 (confirmed via uname -m and by reading the ELF header of the installed claude binary — e_machine=183, genuine AArch64, not a mismatched/corrupted download)
Node.js: v20.19.2 (note: @anthropic-ai/claude-code >= ~2.1.220 declares "engines": {"node": ">=22.0.0"}, producing an EBADENGINE warning on install — see below, this does not appear to be the actual cause)
CLI versions tested, all reproduce identically: 2.1.150, 2.1.220, 2.1.224, 2.1.226
Auth: CLAUDE_CODE_OAUTH_TOKEN (Pro/Max subscription token via claude setup-token), confirmed present and non-empty in the process environment
Symptom
claude -p "<prompt>" --output-format json --allowedTools "" (with the prompt payload piped on stdin) hangs indefinitely — no stdout, no stderr, no exit — until an external timeout wrapper kills it. claude --version and claude --help both return instantly and correctly on every version tested, so the binary itself, PATH, and basic startup are not the issue.
What's been ruled out
Auth token: reproduced identically with the token missing entirely, with a stale token, and with a freshly-generated token via claude setup-token (full container recreate in between). No change.
Network egress: confirmed working at every layer we could test — raw HTTPS GET to api.anthropic.com, console.anthropic.com, and claude.ai all succeed (proper TLS handshake, real HTTP status codes) via both Python's urllib and Node's own fetch() (ruling out an IPv6-specific Node networking issue, a common cause of "Python works, Node hangs").
Stale lock file: found and cleared a stale .claude.json.lock directory (leftover from an earlier hard-killed process) in the CLI's config dir. Did not reappear on retry, did not fix the hang.
CLI version: reproduced on 4 different versions spanning 2.1.150 through 2.1.226.
Node engine mismatch: despite the EBADENGINE warning (CLI wants Node >=22, container has v20.19.2), downgrading to a CLI version with a compatible declared engine range did not change the behavior.
Background/nonessential traffic, CI detection, permission prompts: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, CI=true, and --dangerously-skip-permissions (tested as non-root) made no difference.
Fresh config state: reproduced against a brand-new, never-initialized HOME/CLAUDE_CONFIG_DIR (recreated after a container rebuild wiped the previous session state).
Interactive prompt: attached a real TTY (docker exec -it, no timeout, no redirection) and watched for 30s — nothing is printed at all, ruling out a silent/invisible confirmation prompt.
Diagnostic evidence: strace -f of the hanging process
Traced the full lifecycle from execve to being killed by timeout. Key finding: the trace contains zero socket(), connect(), sendto(), or recvfrom() syscalls anywhere — confirmed via grep -nE "socket\(|connect\(|sendto\(|recvfrom\(" strace.log returning empty across a full 577-line trace. The process never attempts to open a network connection before hanging.
NODE_DEBUG=net,tls,http,http2 (Node's own core-module instrumentation) produces a 0-byte log file for the same reason — the hang happens before any of Node's own networking code runs.
What the trace does show: two threads doing repeated futex(...FUTEX_WAIT_PRIVATE...) cycles (alternating short ~100ms and long ~30s timeouts) and one thread doing repeated pread64() on what appears to be a /proc-style stats file (readings resembling CPU jiffie counters), roughly every 100-800ms, indefinitely. The CLI's config directory also contains a policy-limits.json file, suggesting some kind of internal resource/rate-limit monitor that may be involved in this loop.
This looks consistent with the pattern described in #62957 and #58680 (ARM64 Linux hang, suspected Bun runtime / epoll / non-mainline-kernel interaction) — a Synology NAS runs a heavily vendor-patched, non-mainline ARM64 kernel, which fits that description. However, our specific symptom differs slightly: those reports describe every command hanging (including --version), while in our case only the -p headless/API-call path hangs; simple commands are unaffected.
Reproduction
sh
Minimal repro, isolated environment (mirrors how @anthropic-ai/claude-code
is invoked programmatically via subprocess, e.g. from an automation tool):
env -i PATH="$PATH" HOME=/tmp/claude-home CLAUDE_CONFIG_DIR=/tmp/claude-home \
CLAUDE_CODE_OAUTH_TOKEN="$TOKEN" \
timeout 20 claude -p "ping" --output-format json --allowedTools "" <<< '{}'
echo "EXIT:$?" # always 124 (timeout) on affected systems
Related issues
#62957 — ARM64 aarch64 Linux hang across all commands on a specific version range
#58680 — Jetson Orin AGX (ARM64, out-of-tree kernel) silent startup hang
#13116, #50616, #56540 — various other headless/CI hang reports, possibly related, possibly distinct root causes
Happy to provide the full strace log, container image details, or run further diagnostics on request.
What Should Happen?
claude -p "<prompt>" --output-format json --allowedTools "" (with the prompt payload piped on stdin) hangs indefinitely — no stdout, no stderr, no exit — until an external timeout wrapper kills it. claude --version and claude --help both return instantly and correctly on every version tested, so the binary itself, PATH, and basic startup are not the issue.
Error Messages/Logs
What the trace does show: two threads doing repeated futex(...FUTEX_WAIT_PRIVATE...) cycles (alternating short ~100ms and long ~30s timeouts) and one thread doing repeated pread64() on what appears to be a /proc-style stats file (readings resembling CPU jiffie counters), roughly every 100-800ms, indefinitely. The CLI's config directory also contains a policy-limits.json file, suggesting some kind of internal resource/rate-limit monitor that may be involved in this loop.
This looks consistent with the pattern described in #62957 and #58680 (ARM64 Linux hang, suspected Bun runtime / epoll / non-mainline-kernel interaction) — a Synology NAS runs a heavily vendor-patched, non-mainline ARM64 kernel, which fits that description. However, our specific symptom differs slightly: those reports describe every command hanging (including --version), while in our case only the -p headless/API-call path hangs; simple commands are unaffected.Steps to Reproduce
Reproduction
sh
Minimal repro, isolated environment (mirrors how @anthropic-ai/claude-code
is invoked programmatically via subprocess, e.g. from an automation tool):
env -i PATH="$PATH" HOME=/tmp/claude-home CLAUDE_CONFIG_DIR=/tmp/claude-home \
CLAUDE_CODE_OAUTH_TOKEN="$TOKEN" \
timeout 20 claude -p "ping" --output-format json --allowedTools "" <<< '{}'
echo "EXIT:$?" # always 124 (timeout) on affected systems
Related issues
#62957 — ARM64 aarch64 Linux hang across all commands on a specific version range
#58680 — Jetson Orin AGX (ARM64, out-of-tree kernel) silent startup hang
#13116, #50616, #56540 — various other headless/CI hang reports, possibly related, possibly distinct root causes
Claude Model
Sonnet (default)
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.150, 2.1.220, 2.1.224, 2.1.226
Platform
Other
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Xterm
Additional Information
_No response_