claude-code - 💡(How to fix) Fix Regression: claude hangs post-TLS-handshake in agent loop on Debian 12 (2.1.101+ broken, 2.1.100 works)

Summary

claude (interactive), claude -p, and claude doctor all hang with zero output on a Debian 12 host. Confirmed regression between 2.1.100 (works) and 2.1.140+ (hangs). Same auth, same network, same config — only the binary version differs.

Environment

• OS: Debian 12 (Bookworm)
• Kernel: Linux 6.x x86_64
• Install method: native (Bun-compiled binary at /root/.local/bin/claude)
• Auth: claude.ai OAuth, paid Claude subscription
• autoUpdates: false
• Affected versions: 2.1.140, 2.1.143 (likely entire 2.1.101–2.1.143 range; 2.1.130 returned 404 from install endpoint)
• Last known good: 2.1.100
• Same OAuth account works fine on another machine (active session right now)

Repro

claude -p hi
# timeout 25s, exit 124, 0 bytes of output (stdout AND stderr)

What works on the same host with broken versions

• claude --version — returns version string instantly
• claude --help — returns ~10KB of help text instantly
• claude auth status — returns JSON with org details (so API auth path works end-to-end)
• claude mcp list — returns MCP server list (local-only, no spawn)

What hangs

• claude (interactive)
• claude -p <prompt> (all output formats, with/without stdin, with/without --)
• claude doctor
• All hang with zero bytes on stdout AND stderr, including with --debug enabled

strace observations (key data)

Trace of claude -p hi with -e trace=network,openat,execve,wait4:

• 0.0s–0.6s: binary loads, opens ~150 CA cert PEMs
• 0.7s: spawns /usr/bin/git config --get remote.origin.url (returns instantly)
• 0.7s–1.5s: opens 5+ parallel TLS connections to api.anthropic.com
  • Each: IPv6 connect → ENETUNREACH (no v6 route on this host) → IPv4 falls through → TLS handshake completes
  • HTTP request bytes sent, response bytes received (3–4KB per connection)
• 1.5s–~23s: complete network silence from claude side. Threads spin on futex_wait_bitset_private with EAGAIN returns. Network buffers contain data already received from the server but recvfrom() is not called.
• On SIGTERM (23s): claude finally drains the buffered recvfrom(), then exits with 143

Crucial: the hang is NOT waiting for the network — data was already received and sitting in the socket buffer. Something internal blocks the agent loop from continuing.

Things ruled out

• ❌ Network/firewall: TLS handshakes complete; curl -I https://api.anthropic.com/v1/messages returns 405 in 36ms; no iptables rules on host
• ❌ Auth: auth status returns valid org info; fresh OAuth credentials via claude auth login
• ❌ MCP servers: --strict-mcp-config with {"mcpServers": {}} still hangs
• ❌ Plugins: moved ~/.claude/plugins aside, still hangs
• ❌ Local config / cache: HOME=/tmp/clean-home claude -p hi still produces zero output (exit 0, silent)
• ❌ Binary corruption: claude install --force (same version), then downgrade — different versions hang the same way
• ❌ IPv6 dual-stack penalty: native binary doesn't honor NODE_OPTIONS=--dns-result-order=ipv4first, but happy-eyeballs fallback is <1s — not the hang
• ❌ Argument parsing: -p hi, echo hi | -p, -p -- hi, all hang identically

Workaround

claude install 2.1.100 --force — confirmed working on this host.

Diagnostic artefacts available

Strace output, claude auth status output, .claude.json config (redacted) available on request.