[BUG] Unable to connect to API (ConnectionRefused) on macOS — persists after full reinstall, safe-mode, and reboot (v2.1.204)
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 Code CLI fails on macOS with "Unable to connect to API (ConnectionRefused)" on every request, entering an indefinite retry loop. This matches several closed issues (#17541, #56242, #16331, #33355, #71188, #34982) that appear to be duplicates of the same underlying Bun runtime issue, but none have a confirmed fix, and this is still occurring on a recent version (2.1.204).
What Should Happen?
Claude Code should connect to api.anthropic.com and respond to prompts normally, given that the network, DNS, TLS, and account credentials are all confirmed healthy — verified via curl (GET, POST, and streaming, both IPv4 and IPv6) and via the desktop app connecting successfully from the exact same machine and network.
The CLI should not enter an indefinite "ConnectionRefused" retry loop while curl and the desktop app both reach the same backend without issue.Claude Code should connect to api.anthropic.com and respond to prompts normally, given that the network, DNS, TLS, and account credentials are all confirmed healthy — verified via curl (GET, POST, and streaming, both IPv4 and IPv6) and via the desktop app connecting successfully from the exact same machine and network.
The CLI should not enter an indefinite "ConnectionRefused" retry loop while curl and the desktop app both reach the same backend without issue.
Error Messages/Logs
Full debug log excerpt from ~/.claude/debug/<session-id>.txt:
2026-07-08T19:10:43.787Z [DEBUG] [API REQUEST] /v1/messages source=repl_main_thread
2026-07-08T19:10:43.822Z [ERROR] API error (attempt 1/11): undefined Connection error.
2026-07-08T19:10:43.838Z [DEBUG] [shoji-engine] yield system/api_error
2026-07-08T19:10:44.423Z [DEBUG] [API:timing] dispatching to firstParty model=claude-sonnet-5
2026-07-08T19:10:44.425Z [DEBUG] [API REQUEST] /v1/messages source=repl_main_thread
2026-07-08T19:10:44.426Z [ERROR] API error (attempt 2/11): undefined Connection error.
2026-07-08T19:10:44.426Z [DEBUG] [shoji-engine] yield system/api_error
2026-07-08T19:10:45.448Z [DEBUG] [API:timing] dispatching to firstParty model=claude-sonnet-5
2026-07-08T19:10:45.450Z [DEBUG] [API REQUEST] /v1/messages source=repl_main_thread
2026-07-08T19:10:45.451Z [ERROR] API error (attempt 3/11): undefined Connection error.
2026-07-08T19:10:45.452Z [DEBUG] [shoji-engine] yield system/api_error
[... pattern repeats through attempt 8/11 with exponential backoff (1s, 1s, 1s, 2s, 4s, 8s, 20s, 36s...) ...]
UI-visible error:
Unable to connect to API (ConnectionRefused) · Retrying in Ns · attempt N/10
No error.code, error.cause, errno, address, or port is surfaced anywhere in the log — the underlying cause of "Connection error" is not exposed.
Steps to Reproduce
- Launch claude in a terminal (tested in Warp)
- Enter any prompt (e.g., "hola")
- Observe: "Unable to connect to API (ConnectionRefused) · Retrying in Ns · attempt N/10"
- The retry loop runs through all attempts (up to 11) and never recovers
- Reproducible across:
- Multiple terminal restarts and multiple new terminal tabs
- claude --safe-mode (all customizations disabled)
- claude --model opus (different model)
- An older CLI version (2.1.201, run directly via its binary path)
- A full system reboot
- A full clean reinstall (rm -rf ~/.local/share/claude, rm ~/.local/bin/claude, then curl -fsSL https://claude.ai/install.sh | bash)
- In parallel, on the same machine and network:
- The Claude desktop app connects and works normally
- curl to api.anthropic.com (GET, POST to /v1/messages, and streaming POST) all succeed
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.203 (worked normally on July 7, 2026 before updating to 2.1.204)
Claude Code Version
2.1.204 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Warp
Additional Information
This appears to be a Bun runtime issue, not a network/config issue on my end — see extensive verification below.
Related closed issues describing the same symptom (all appear to be duplicates of the same underlying problem, none with a confirmed fix):
- #17541 — Connection Refused despite successful curl, notes it's likely a Bun HTTP client issue
- #56242 — Same pattern: CLI and Cowork fail while claude.ai web works fine
- #16331 — Original report of this exact error
- #33355 — Closed as stale, same symptom
- #71188 — Same symptom, recent
- #34982 — Technical root cause candidate: confirms the Bun runtime bundled in the CLI binary fails at the TCP socket level (FailedToOpenSocket/ConnectionRefused) before any HTTP request is made, while the identical JS codebase works fine on Node.js (e.g., in the VS Code extension host). Same code, same config, different runtime, different result.
Context that ruled out a local/config cause:
- No proxy, no ANTHROPIC_BASE_URL, no NODE_OPTIONS set anywhere (shell env, ~/.claude.json, ~/.claude/settings.json)
- macOS Application Firewall not blocking the binary; global state = 1 (not strict)
- pf (packet filter) disabled; no MDM profiles
- Tailscale daemon was down (no active socket) and AdGuard network extension was fully removed — no change
- Route to api.anthropic.com confirmed going through the normal en0 (Wi-Fi) interface
- Code signature valid: Developer ID Application: Anthropic PBC (Q6L2SF6YDW), hardened runtime, full chain to Apple Root CA — binary is not corrupted or tampered
- No sandboxing entitlements restricting network access
- claude --safe-mode (all plugins/skills/hooks/MCP disabled) — still fails identically, ruling out any local configuration/plugin cause
Interesting observation: while the CLI is stuck in the "ConnectionRefused" retry loop, sudo lsof -i -P -n -p <CLI PID> shows several TCP connections to 160.79.104.10:443 (api.anthropic.com) in ESTABLISHED state at the same time the CLI reports the connection as refused — suggesting the error surfaced to the user may not reflect the actual socket state, consistent with #34982's finding.
Happy to provide the full raw debug log file (~/.claude/debug/<session-id>.txt) privately if useful — didn't want to paste the entire multi-hundred-line file here since it contains session IDs and internal identifiers.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗