Your session was fine ten minutes ago. Now Claude Code just stops mid-task, with no error worth Googling. You restart it. It works for a while, then stalls again. It works on your colleague's machine, two desks over, which somehow makes it worse. You start wondering if the model got worse today, if your laptop needs a reboot, or if you're somehow holding the tool wrong.
Your tool isn't broken. Your network is lying to you.
This is what living with AI tools behind a corporate proxy actually feels like most days, and by the end of this article, you'll know exactly what your network is doing to your traffic, plus the exact commands to fix the right layer instead of guessing at the wrong one.
⏱ 20 min read Updated September 2026
The 60-Second Diagnostic Table for AI Tools Behind a Corporate Proxy
Corporate TLS inspection — also called SSL inspection or a man-in-the-middle proxy — intercepts your encrypted traffic, decrypts it, inspects it, and re-encrypts it with its own certificate before forwarding it on. It's built for security scanning. Most AI dev tools were never built to expect it.
Before you jump to fixes, run this once: curl -v https://api.anthropic.com. If the certificate issuer shown in the output names your company or a security product instead of a public CA, you're dealing with TLS inspection; skip straight to "Diagnosing Each Failure Mode" below. If the certificate is a public CA and the request succeeds, your problem is more likely the idle-timeout or buffering issue; skip to "Why Streaming Breaks Silently." That one command saves you from applying a certificate fix to a timeout problem, or vice versa.
When the Tool Just Says "Check Your Connection"
Not everyone hitting this problem gets a tidy error string to search for, and that's true whether the tool in front of you is Claude Code, Cursor, or GitHub Copilot. A lot of people just get a wall. On the Cursor forum, one user's entire report was: "Connection failed… please check your internet connection or VPN. Ping timed out. Unavailable." Another described the tool getting "very slow… and keep disconnecting with errors." A third simply wrote "Taking longer than expected" and left it at that. Someone summed up months of this as "claude ai not finishing prompt requests lately", no certificate name, no stack trace, just a tool that quietly stops delivering.
If you're this reader, you're not behind, you just haven't been shown the layer where the failure actually lives claude code econnreset and "connection closed mid-response" are the same story with a more technical name attached.
Here's the one test that tells you whether it's your network or something else: run the exact same request from your phone's hotspot, off the company network entirely. If it works there and fails on the office connection, the cause is confirmed. It's the network in between, not the tool, not the model, and not you. Keep reading, because the next two sections tell you exactly which piece of that network is responsible, and how to prove it.
Why One Cause Breaks Four Different Ways
Here's the part that makes this genuinely confusing: a cert error, a silent stall, a vague "check your connection" message, and a mid-task disconnect don't look like the same bug. They aren't caused by four different problems. They're caused by where in the request your corporate proxy decides to step in.
A request to an AI API has two distinct moments a proxy can interfere with. The first is the TLS handshake, the instant your tool tries to establish an encrypted connection. If the proxy intercepts here, it re-signs the traffic with its own internal certificate authority, and your tool either trusts that CA or throws a certificate error. That's the noisy failure mode: self signed certificate in certificate chain, unable to get local issuer certificate.
The second moment is mid-stream, after the connection is already open and the model is sending tokens back. This is where proxies buffer, throttle, or apply idle timeouts, and it's where the silent failures live. Claude Code, for example, runs four separate watchdog timers on a streaming response: first-byte, event-level, byte-level, and body-idle (in plain terms: one for the very first byte arriving, one for each new chunk of text, one for bytes still trickling in, and one for the whole response staying silent too long). If any of them goes quiet for too long, it abandons the response rather than hang forever. From the outside, that looks like the tool "just stopping." It's actually a safety mechanism reacting correctly to a network that went silent on it.
One more wrinkle worth knowing: Claude Code doesn't support SOCKS proxies at all, it only reads HTTPS_PROXY, HTTP_PROXY, and NO_PROXY (lowercase variants included). If your network hands your machine a SOCKS proxy, the tool simply won't use it, which is exactly why your proxy variables can look completely ignored even when you've set them correctly.
This also isn't unique to the Claude Code CLI. The same root cause — a bundled runtime that doesn't fully inherit the OS's or an environment variable's CA trust — has separately surfaced in Claude Desktop's Code pane, Claude Cowork, the VS Code extension, and the "Claude in Chrome" WebSocket bridge. If you're hitting a certificate error in any of those surfaces behind TLS inspection, the diagnosis below still applies: the client is different, the cause is the same.
Diagnosing Each Failure Mode
Each of the four errors below has a distinct mechanism and an actual fix, not just a diagnosis. Match your symptom, run the confirm command, then run the fix for your operating system.
1. "self-signed certificate in certificate chain"
This fires the moment your tool receives a certificate it doesn't recognize, specifically one signed by your company's internal certificate authority instead of a public one. Your tool checks incoming certificates against its trust store (the list of certificate authorities it already trusts by default), and an internal CA usually isn't on that list. The proxy isn't malicious here; it's doing exactly what TLS inspection is designed to do.
Before either fix below does anything, you need that CA certificate file, and you won't have it lying around. Ask your IT team for it; the ticket in "What to Send Your IT Team" further down already requests it, or, if your machine already trusts the proxy system-wide, export it from your operating system's certificate trust store. Once you have a .pem file, point the variable below at it.
# Confirm it
openssl s_client -connect api.anthropic.com:443 -showcerts# If the "issuer" or "O=" line shows your company name or a
# security product instead of a public CA, that's TLS
# inspection confirmed.# Fix it — macOS/Linux
export NODE_EXTRA_CA_CERTS=/path/to/company-ca.pem# Fix it — Windows (PowerShell)
setx NODE_EXTRA_CA_CERTS "C:\path\to\company-ca.pem"
Current documentation already describes CLAUDE_CODE_CERT_STORE as the fix for this exact scenario, so the issue appears to have been addressed.
2. "unable to get local issuer certificate"
This is Node and npm's version of the same story, and it's one of the most commonly reported proxy errors in JavaScript tooling. It shows up when the proxy re-signs traffic with an internal CA that Node's own certificate store doesn't trust, sometimes as this exact message, sometimes as its all-caps sibling UNABLE_TO_GET_ISSUER_CERT_LOCALLY which shows up in some native-build error output for the identical underlying cause.
# Confirm it
openssl s_client -connect registry.npmjs.org:443 -showcerts# If the handshake completes but shows "unable to get local
# issuer certificate" or a non-zero verify return code, Node
# doesn't trust the signing CA yet.# Fix it — macOS/Linux
export NODE_EXTRA_CA_CERTS=/path/to/company-ca.pem# Fix it — Windows (PowerShell)
setx NODE_EXTRA_CA_CERTS "C:\path\to\company-ca.pem"
That's the correct fix, pointing Node at the internal CA explicitly. Disabling certificate checking instead makes the symptom disappear while leaving you with zero protection against a real man-in-the-middle attack, which is a trade you don't want to make just to silence an error.
3. "NODE_EXTRA_CA_CERTS not working"
Here's where it gets frustrating: setting NODE_EXTRA_CA_CERTS correctly is supposed to be the fix, and sometimes it just isn't.
# Confirm the variable is actually set and the file exists
# macOS/Linux
echo $NODE_EXTRA_CA_CERTS && ls -l "$NODE_EXTRA_CA_CERTS"# Windows (PowerShell)
$env:NODE_EXTRA_CA_CERTS; Test-Path $env:NODE_EXTRA_CA_CERTS# If either command comes back empty or "False", the variable
# isn't reaching the process — often because it was set in the
# wrong shell, or your tool bundles a runtime that ignores it.
There's a reported case of exactly this failing on the Bun runtime behind Zscaler, where the variable was set correctly, and the certificate error persisted anyway. One user described the exact sequence: "Set NODE_EXTRA_CA_CERTS… the error persisted. Set SSL_CERT_FILE… the error persisted." Different JavaScript runtimes read certificate configuration differently, and a fix that works for Node doesn't automatically carry over to Bun or to a tool's bundled binary.
The mechanism is specific: Claude Code's Bun-compiled binary loads trusted certificates in layers, bundled Mozilla CAs first, then the system keychain if enabled, then anything pointed to by NODE_EXTRA_CA_CERTS, but the WebFetch tool's internal HTTP client builds its own request dispatcher that doesn't reliably inherit that patched CA store. That's why the variable can be set correctly, the file can be readable, and the error still fires. This is a documented runtime-level gap, not something you configured wrong. If you've verified the variable is set and the file is readable and the error persists, stop tuning certificates and take it to your IT team using the paragraph in "What to Send Your IT Team" below.
4. "stream ended unexpectedly" (and sporadic ECONNRESET)
This one isn't a handshake problem. It happens after the connection is already trusted and working. Sessions dropping mid-task and streams that just end without warning are classic symptoms of a middlebox (network equipment sitting between you and the internet, inspecting or relaying traffic in transit) applying an idle timeout, commonly somewhere in the 30-to-60-second range. If a response goes quiet for a stretch longer than that window — which happens naturally when a model is "thinking" between tokens — the middlebox can simply close the connection, and your tool has no way to know that wasn't intentional.
There is no client-side fix for this one. The timeout lives on network equipment you don't control. Take it straight to your IT team using the paragraph in "What to Send Your IT Team" below.
# Confirm it — this holds a connection open and idle for 45
# seconds, enough to trip most corporate idle timeouts
curl -v https://httpbin.org/delay/45# If the connection resets or drops before the 45 seconds are
# up, your proxy is closing idle connections early — that's
# your cause confirmed.
Why Streaming Breaks Silently: The SSE Buffering Problem
This is the mechanism behind most of the "it's just slow" complaints, and it has nothing to do with certificates.
AI tools stream responses using Server-Sent Events (SSE), a format designed to deliver small chunks of text the moment they're generated, so you see the response build token by token. Reverse proxies like Nginx and Cloudflare, in their default configuration, buffer a response until they see either a Content-Length header or the connection closing. SSE responses provide neither: the length isn't known in advance, and the connection stays open for the whole stream on purpose.
The result is that the proxy sits there collecting the entire response internally, and only releases it to you in one burst once the model finishes. To you, this looks exactly like a hang. The tool isn't frozen, and the model isn't slow; the response is sitting fully formed on a piece of network equipment that's waiting for a signal SSE was never going to send.
Cursor's own enterprise documentation describes this same class of failure without naming specific error strings — truncated responses over HTTP/2 (the connection protocol most of these tools use to talk to their API) and streaming that buffers instead of arriving incrementally, both consistent with a proxy holding the connection open longer than the client expects.
The Trap After the Fix: MCP Servers Make Their Own Calls
Here's a failure worth knowing about before it wastes your afternoon: you can fix the certificate error, get the main connection working, and still see network failures, because MCP (Model Context Protocol) servers you've connected often make their own independent outbound HTTPS requests, outside the connection you just fixed.
If you've added an MCP server — for a database, an internal API, a ticketing system, anything — it typically runs as its own process with its own network stack. Setting NODE_EXTRA_CA_CERTS for your main tool doesn't automatically extend to every MCP server's outbound calls; each one may need the same certificate trust configured separately, and some fail with the same TLS errors you just spent an hour solving for the main connection. If you fix the primary API error and then hit fetch failed or a certificate error the moment you use an MCP-backed tool, this is why: you're looking at a second, independent instance of the exact same problem, not a regression of the fix you already applied.
What to Send Your IT Team
You usually can't change how your company's proxy is configured, but whether you're troubleshooting Claude Code, Cursor, or Copilot, you can ask for the right thing instead of the vague thing. Here's a paragraph you can copy directly into a ticket:
"I'm using an AI coding tool that connects over HTTPS and depends on streaming responses (Server-Sent Events) to work correctly. Could you confirm whether our proxy performs TLS/SSL inspection on this traffic, and if so, whether the internal CA certificate can be provided to me so I can configure my tool to trust it? Separately, could you check whether the proxy buffers streaming responses or applies an idle timeout under roughly 60 seconds, either one will cause the tool to disconnect or appear to hang mid-response."
That's specific enough for a network engineer to act on without you needing to know their tooling. It also signals that you understand this is a configuration question, not a "please turn off security" request, which matters for how fast you get a useful answer.
The Fix That Isn't a Fix: Why You Should Never Disable Certificate Validation
At some point, tired and behind on a task, you will find the setting that makes the certificate error go away entirely: NODE_TLS_REJECT_UNAUTHORIZED=0, curl -k, or whatever your tool's equivalent flag is called. Don't use it.
This isn't a style preference, it's a genuine security decision, and a bad one. One security researcher put it plainly: "'Oh, it's probably just the corporate proxy again' becomes the reflexive response to any TLS error," and disabling verification quietly turns into "a routine troubleshooting step" instead of the exception it should be. Once certificate validation is off, your tool can't tell the difference between your company's inspection proxy and an actual attacker sitting on the same network intercepting your traffic, which defeats the entire point of HTTPS. The fix that actually works is teaching your tool to trust the right certificate authority, via NODE_EXTRA_CA_CERTS, CLAUDE_CODE_CERT_STORE, or your tool's documented equivalent, not telling it to stop checking altogether.
Your tool was never the problem. The network was rewriting your traffic the whole time, and now you know exactly where to look and what to run to prove it.