⎿  API Error: Unable to connect to API...

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/53345
2. https://github.com/anthropics/claude-code/issues/47369
3. https://github.com/anthropics/claude-code/issues/43516

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Unable to Connect ti Claude code. Blank Scrren for last 30 minutes. Loss of produictive hrs.

+1 — same symptom on May 5, 2026 (UTC).

Environment:

• Mac mini M4, macOS: 26.4.1（25E253）
• Claude Code version:　v2.1.128
• Terminal: Apple_Terminal

Observations:

• Same Unable to connect to API (ConnectionRefused) retry loop
• Claude Cowork on the same machine also fails to authenticate
• Claude.ai in the browser works normally on the same machine and network
• The official status page reports "no incidents today," but May 4, 2026 had multiple resolved incidents on Claude API / Code / Cowork; the client-side fallout appears to persist beyond the status page acknowledgment

This issue has been open since April 25, 2026 — would appreciate any update from the team. The recurring pattern across #16331, #17541, #33355, #53346, #56017, #56140 suggests an unresolved root cause rather than per-incident network problems.

Also experiencing this issue, an update would be appreciated.

Reproducing this on macOS 26.5 with Claude Code v2.1.143 — still unresolved on later versions. Adding diagnostic data in case it helps identify a fix.

Environment

• OS: macOS 26.5 (Build 25F71) — Tahoe
• Hardware: MacBook Pro 16-inch 2019, Intel x86_64
• Claude Code: v2.1.143 (native binary at ~/.local/bin/claude → ~/.local/share/claude/versions/2.1.143)
• Bun: v1.3.14 (upgraded from v1.3.8, no change)
• Plan: Claude Max (OAuth via subscription)
• Terminals tested: Ghostty, Terminal.app (both affected)

Symptoms

Identical to OP — Unable to connect to API (ConnectionRefused/ECONNRESET) on every prompt submission, with retry loop. Authentication itself succeeds ("Welcome back" displayed, oauthAccount populated, Keychain entry written), but the moment a prompt is sent, the connection fails.

Diagnostic: no outbound packets are emitted

macOS SFA-rootNetworking.json diagnostic report (~/Library/Logs/DiagnosticReports/) during the failing session:

{
  "eventType": "rootNetworkingHealthSummary",
  "success_count": 0,
  "soft_failure_count": 0,
  "hard_failure_count": 0
}

Zero successes, zero failures — meaning Claude Code's HTTPS layer is not emitting outbound packets at all. This is consistent with the diagnosis in the original report that Bun's HTTP client is failing before the connection is established.

Meanwhile, the network path is fully healthy from the same shell:

$ curl -I https://api.anthropic.com
HTTP/2 404
server: cloudflare

What I ruled out (none resolved the issue)

• Network/DNS — curl to api.anthropic.com succeeds, TLS handshake OK
• System proxies — disabled across all network services (Wi-Fi, VPN interfaces)
• Environment variables — no HTTP_PROXY, HTTPS_PROXY, ANTHROPIC_*, CLAUDE_* set
• VPN — WireGuard / ProtonVPN inactive
• Firewall — socketfilterfw --getappblocked reports claude as permitted; firewall global state checked, no blocking rules
• Application Firewall — explicitly added Claude binary via --add and --unblockapp
• Auth state — ~/.claude.json oauthAccount populated correctly; macOS Keychain Claude Code-credentials entry exists and refreshes on /login
• policy-limits.json — removed and regenerated, no effect
• Plugins — disabled claude-mem, no change
• MCP servers — all 7 configured servers temporarily removed from ~/.claude.json, no change
• settings.json — replaced with minimal config ({"permissions": {"defaultMode": "auto"}}), no change
• Older binary — ran versions/2.1.141 directly, same error
• Bun upgrade — bun upgrade from v1.3.8 → v1.3.14, no change
• npm/native conflict — removed the npm-global @anthropic-ai/claude-code per the binary's own warning, no change
• Full reinstall — wiped ~/.claude/, ~/.claude.json, Keychain credential, reauthenticated, same error
• DNS cache — dscacheutil -flushcache + killall -HUP mDNSResponder, no change
• Local Network privacy reset — tccutil reset SystemPolicyAllFiles, no change

Side note: related local-loopback failure

In my case the retry loop also coincided with a Connection refused to 127.0.0.1:37777 (the claude-mem worker socket), but disabling claude-mem and killing all worker/chroma processes did not fix the upstream api.anthropic.com connectivity. The two appear to share a root cause in how Bun's networking interacts with macOS Tahoe 26.x.

Reproduction

100% reproducible on every prompt submission, immediately after a clean install. Auth flow completes, then the very first hello triggers the retry loop.

Happy to attach ~/.claude/debug/ contents, lsof -p <claude_pid> output, or run any further diagnostic commands the maintainers want.

---

Related reports (same root cause, different macOS Tahoe builds):

• #38977 — macOS 26.3.1 Tahoe, Intel x86_64
• #53346 — macOS, ConnectionRefused
• #59576 — macOS Tahoe 26.5, Cowork affected

<html><head></head><body><h2>Follow-up: Further diagnostic findings on macOS 26.5</h2>
<p>After extensive additional debugging, I can confirm the root cause is in the <strong>bundled Bun runtime's HTTP layer</strong>, specifically when handling connections to <code>api.anthropic.com</code>. Here's what I found:</p>
<h3>Key isolation test: bundled Bun vs system Bun</h3>
<pre><code class="language-bash"># System Bun (1.4.0-canary.1+ad68af805) — 10 consecutive POSTs to api.anthropic.com
$ for i in {1..10}; do
bun -e "fetch('https://api.anthropic.com/v1/messages', {method: 'POST'}).then(r =&gt; console.log('Status:', r.status)).catch(e =&gt; console.log('FAIL:', e.message))"
done
Attempt 1: Status: 401
Attempt 2: FAIL: Unable to connect. Is the computer able to access the url?
Attempt 3: Status: 401
Attempt 4: Status: 401
Attempt 5: Status: 401
Attempt 6: Status: 401
Attempt 7: Status: 401
Attempt 8: Status: 401
Attempt 9: Status: 401
Attempt 10: Status: 401
</code></pre>
<p>System Bun succeeds ~90% of the time (1 intermittent failure out of 10). But:</p>
<pre><code class="language-bash"># Claude Code (bundled Bun) — every single call fails
$ claude -p "hello"
API Error: Unable to connect to API (ECONNRESET)
</code></pre>
<p>Same machine, same network, same moment. <strong>System Bun mostly works, bundled Bun never works.</strong> The bundled Bun appears to be on an older version and/or has different network configuration.</p>
<h3>Domain-specific failure</h3>
<p>Bun's failure is <strong>specific to <code>api.anthropic.com</code></strong> — other Anthropic domains work fine:</p>
<pre><code class="language-bash">$ bun -e "fetch('https://example.com').then(r =&gt; console.log(r.status))"
Status: 200

$ bun -e "fetch('https://statsig.anthropic.com').then(r =&gt; console.log(r.status))"
Status: 530 # Reaches Cloudflare, gets an error — but connection succeeds

$ bun -e "fetch('https://console.anthropic.com').then(r =&gt; console.log(r.status))"
Status: 200

$ bun -e "fetch('https://api.anthropic.com/v1/messages', {method: 'POST'}).then(r =&gt; console.log(r.status))"
Error: Unable to connect. Is the computer able to access the url? # When it fails
</code></pre>
<p>This matches OP's observation about <code>mcp-proxy.anthropic.com</code> working — the failure is targeted at <code>api.anthropic.com</code> specifically, not Bun networking in general.</p>
<h3>Likely related: stale HTTP/2 connection pool (see #23744)</h3>
<p>The intermittent nature of system Bun failures (1/10) suggests <strong>stale connection pooling</strong>: Bun's HTTP/2 client may be reusing a half-dead socket. Since Claude Code is a long-running process making many sequential API calls, it almost always hits this stale-socket condition, while one-shot Bun invocations from CLI mostly succeed (fresh connection per process).</p>
<p>This aligns with #23744's diagnosis: <em>"the old socket is dead but Claude Code keeps trying to reuse it."</em></p>
<h3>Things that did NOT help</h3>

Attempt | Result
-- | --
sudo networksetup -setv6off Wi-Fi (disable IPv6, per #20240) | No change
/etc/hosts IPv4 override for api.anthropic.com | No change
sudo dscacheutil -flushcache && killall -HUP mDNSResponder | No change
bun upgrade --canary to 1.4.0-canary (system Bun) | System Bun improved to 90% success; Claude Code unchanged (uses bundled Bun)
Killing all Claude / Chrome native host / claude-mem processes | Eliminates a separate ConnectionRefused issue but bundled-Bun ECONNRESET persists
Full clean reinstall via npx claude-mem@latest install, npm uninstall/install, removed ~/.claude/, ~/.claude.json, Keychain credentials | No change
claude -p "hello" (print mode, per #25229) | Also fails with ECONNRESET

<h3>Note on <code>chrome-native-host</code> ghost process</h3>
<p>A separate (likely unrelated) issue I uncovered during diagnosis: when Remote Control is used heavily via the mobile app, <code>Claude.app</code>'s <code>Helpers/chrome-native-host</code> process can be left running indefinitely with a stale socket at <code>/private/tmp/claude-mcp-browser-bridge-&lt;user&gt;/</code>. While this process is alive, Claude Code in the terminal reports <code>ConnectionRefused</code> (not ECONNRESET) — a different error code, but the user-facing symptom (retry loop) looks identical. Killing the orphaned process and removing the socket directory cleared <code>ConnectionRefused</code>, leaving only the underlying ECONNRESET to deal with. Filing separately would clutter this thread, but flagging here in case it correlates.</p>
<h3>Suggested next step for maintainers</h3>
<p>Could you confirm what Bun version is bundled in current Claude Code releases (v2.1.140+)? If it's significantly older than 1.4.x, an upgrade may resolve the intermittent connection pool issue. Alternatively, the underlying HTTP client could be configured to disable HTTP/2 connection reuse for <code>api.anthropic.com</code> as a temporary mitigation — at the cost of some performance, this would sidestep the stale-socket condition entirely.</p>
<p>Happy to capture additional diagnostics (<code>strace</code>/<code>dtrace</code>, <code>tcpdump</code>, debug logs) if specific traces would help.</p></body></html>

I uninstalled the claude-mem and superpower, then the error disappear. I dont know the reason but you could try it.

Is there any solution onto this?

I now solved the issue. There was an environment variable for the Anthropic api key, which was wrong. /doctor brought this up.

@Ninerian what was the variable? Please share some details about this.

happening with me with subscription, api key won;t work in my case

I had the same error and was able to resolve it this morning, so I wanted to share my scenario in case it helps anyone.

I have been using headroom to help mitigate some of the token costs for Claude Code locally. Headroom encourages you to run a local proxy and point your Anthropic base URL to that proxy (like .claude/settings.local.json:3: "ANTHROPIC_BASE_URL": "http://127.0.0.1:8787").

For myself, I had been running the proxy for a long time and forgot about it. I restarted my computer, which killed the proxy, making my Anthropic base URL pointer invalid. My solution was to just spin up Headroom again. The other solution was to remove the environment variable, ANTHROPIC_BASE_URL, which would allow for requests to go to the default anthropic base URL.

---

A couple of notes on testing/diagnosing..

1. Try to open Claude in a different directory than what you're used to. For example, cd /tpm && claude. If this works, then you know something is wrong with your local workspace environment (<path-to-project>/.claude).
2. You can run Claude in debug mode like claude --debug. This will output the logs to a file, which you can review and diagnose further. When I was troubleshooting, I fed these logs to Claude in the web browser, which helped me understand what was going on