Claude Code — unable to connect to API

ECONNRESET, ECONNREFUSED and certificate failures wear the same message. The one that has a fix, the one that doesn't, and the test that tells them apart.

Last reviewed 2026-08-07 · verified against the pingdotgg/t3code repo

API Error: Unable to connect to API (ECONNRESET)
Unable to connect to API (ECONNREFUSED)
Unable to connect to API (ConnectionRefused)
Unable to connect to API (UND_ERR_INVALID_ARG)
OAuth error: The socket connection was closed unexpectedly
unable to verify the first certificate
unable to get local issuer certificate

Seven strings, three unrelated causes. One of them has a real fix, one is an open bug with none, and one isn't Claude Code's fault at all. Work out which you have before changing anything.

The test that splits them#

Run these while Claude Code is failing. This is the diagnostic from #62045, where the reporter proved the network was healthy and only the client was broken:

ping api.anthropic.com

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://api.anthropic.com/v1/messages

A 405 back from curl is correct — it means you reached Anthropic and the endpoint rejected a bare GET. That's a success for this purpose.

1. Corporate proxy or TLS inspection#

This is the cause with a fix, so rule it in or out first. If you're on a company network running Zscaler, Netskope, a corporate firewall, or any TLS-inspecting middlebox, it re-signs HTTPS traffic with a private root CA that Claude Code doesn't trust.

The trap: Claude Code runs on Bun, not Node#

Nearly everyone reaches for NODE_EXTRA_CA_CERTS. It often does nothing, and the reason is non-obvious: the claude binary is compiled with the Bun runtime, not standard Node.js.

That single fact explains a whole family of reports — #25977, #26897, #22512, #70394, #24916 — all of them "I set NODE_EXTRA_CA_CERTS correctly and it's still failing."

What to try instead#

On macOS, tell the runtime to read the system keychain, where your corporate root is already installed:

export NODE_USE_SYSTEM_CA=1

That is the reported workaround for the Bun/Zscaler case, and it sidesteps the file-path question entirely.

If you still need to point at a file, export the corporate root as PEM first:

export NODE_EXTRA_CA_CERTS="/path/to/corporate-root-ca.pem"

If the CLI works but the desktop app doesn't#

A recurring split: the terminal CLI connects fine with your cert configuration, while the Code tab in Claude Desktop fails — reported on Windows MSIX installs (#70394) and on macOS (#24916).

The desktop app doesn't inherit your shell environment, so exports you made in a terminal never reach it. Use the CLI on a corporate network until that's resolved — it's the reliable path, not a downgrade.

2. The HTTP/2 connection-pool bug#

If curl, ping and Node all succeed while only Claude Code throws ECONNRESET, you're most likely looking at this. There is no confirmed fix.

#62045 documents it about as thoroughly as a bug report can be. On Windows, Claude Code 2.1.150, wired ethernet, no VPN or proxy, the reporter ran all three checks while the client was failing:

ping   → 50/50 packets, 0% loss, 15-39ms
curl   → 405 in ~0.1s
node   → status 401

All healthy. Only Claude Code reset. They then ruled out, one at a time:

• IPv6 — disabled at adapter level, no change
• Proxy — netsh winhttp show proxy showed direct access, no *_PROXY vars
• Antivirus — Malwarebytes and Defender both disabled, no change

The diagnosis: stale HTTP/2 connection-pool reuse. The tell is the behaviour pattern —

Fresh sessions work briefly, then begin hanging and resetting after a few turns. Restarting the process helps temporarily, then it recurs.

That's a dead socket being reused from a pool, not a network fault. Short prompts survive; long sessions drop after a few minutes.

#56711 is the macOS counterpart, on 2.1.131, Apple Silicon. That reporter tried a genuinely exhaustive list before filing:

rm -rf ~/.claude
rm -rf ~/Library/Application\ Support/Claude/claude-code
npm i -g @anthropic-ai/claude-code       # clean reinstall
NODE_OPTIONS="--dns-result-order=ipv4first" claude

…plus full restarts, sign out and in, and switching from Wi-Fi to a phone hotspot. None of it worked.

What is actually worth trying#

• Restart the process when it starts degrading. It buys a fresh pool and a few more turns. Not a fix, but it's the only lever that reliably does anything.
• Update. These reports span 2.1.131 through 2.1.150; connection handling is exactly the kind of thing that changes between builds.

npm i -g @anthropic-ai/claude-code@latest
claude --version

• Prefer shorter sessions on affected setups. The failure correlates with session length, so /clear between tasks costs less than a mid-run reset.
• Try the CLI if you're in the desktop app, or vice versa. In several reports one worked while the other didn't.

The upstream fix people have asked for is to force-close the connection pool on ECONNRESET rather than reusing a dead socket, and to expose an HTTP/1.1 fallback. Neither exists yet.

3. Actually the network#

If curl fails too, Claude Code isn't the problem.

ping api.anthropic.com
nslookup api.anthropic.com

Worth checking in order: VPN split-tunnel rules, DNS (try 1.1.1.1), a firewall blocking outbound 443 to api.anthropic.com, and — if you're on a network that filters by region — whether the endpoint is reachable at all.

ECONNREFUSED specifically means something actively rejected the connection rather than dropping it, which points at a firewall or a proxy that isn't where Claude Code expects one (#18766, #71188).

Where to check your exact variant#

A useful report includes the exact error code in parentheses, your claude --version, OS and install method, whether you're behind a proxy, and the curl result from the top of this page. Without that last one the first reply will just ask for it.

FAQ#

What does "Unable to connect to API (ECONNRESET)" mean in Claude Code?#

The TCP connection to Anthropic's API was reset before the request finished. If curl and ping to api.anthropic.com succeed at the same moment, the reset is happening inside Claude Code's own HTTP client rather than on the network — most likely stale HTTP/2 connection-pool reuse.

Why doesn't NODE_EXTRA_CA_CERTS work with Claude Code?#

Because the claude binary is compiled with the Bun runtime rather than standard Node.js, so a Node-specific certificate variable may be ignored. On macOS, NODE_USE_SYSTEM_CA=1 is the reported workaround, since it makes the runtime read the system keychain where your corporate root already lives.

Claude Code fails but curl works — what does that tell me?#

That your network, DNS and TLS are fine and the fault is in the client. That pattern matches the open HTTP/2 connection-pool reports, for which there is no confirmed fix; restarting the process buys a fresh pool temporarily.

Is there a fix for the ECONNRESET bug?#

Not a confirmed one. The two most thorough reports were closed as "not planned" after their authors had already tried clean reinstalls, network switches, IPv6 disabling and antivirus removal. Restarting when sessions start degrading, and keeping the CLI updated, are the only things that help.

Why does the CLI work but the Claude Desktop Code tab fail?#

The desktop app doesn't inherit your shell environment, so certificate variables you exported in a terminal never reach it. Behind a corporate proxy, the terminal CLI is the reliable path.