Fix "ProxyResponseError: response does not appear to originate from GitHub"

GitHub Copilot CLI prints this when the reply it received did not come from GitHub:

execution failed: ProxyResponseError: HTTP 503 response does not appear to
originate from GitHub. Is a proxy or firewall intercepting this request?
https://gh.io/copilot-firewall

The status code varies — HTTP 403 is the other common one — but the meaning does not. This is not a GitHub outage, and it is not a problem with your token, your licence or your install. Copilot CLI checked the response for GitHub's own signature, did not find it, and is telling you that something on your network answered on GitHub's behalf.

Confirm that in ten seconds:

curl -sS -o /dev/null -w '%{http_code}\n' https://api.github.com/

A 200 from curl while Copilot CLI still fails means the interception is selective — see the proxy environment section. Anything else, or a certificate error, and you have found your culprit.

Confirm what is intercepting you

Read the certificate that your machine is actually being served for GitHub:

curl -sSv https://api.github.com/ 2>&1 | grep -iE "issuer|subject|subjectAltName"

On an unintercepted connection the issuer is a public certificate authority. If it instead names your employer, or a security vendor — Zscaler, Netskope, Palo Alto, Forcepoint, Blue Coat, Cisco Umbrella and similar — then TLS inspection is active. The appliance is terminating your HTTPS connection, reading it, and re-signing it with its own CA. When its policy blocks the destination, it returns its own error page, and that page is what Copilot CLI is rejecting.

The other quick confirmation is to look at what actually came back:

curl -sS -D - https://api.github.com/ -o /tmp/gh-body.txt | head -20
cat /tmp/gh-body.txt | head -20

A block page announces itself. Expect an HTML body with your security vendor's branding, a policy or category name, and often a reference ID for your helpdesk. Capture that reference — it is the single most useful thing to hand IT.

Fix 1: Get the Copilot domains allowlisted

The URL in the error message, gh.io/copilot-firewall, is GitHub's own current allowlist, and it is there because this is the most common cause. At minimum, Copilot CLI needs these on port 443:

Two details make the difference between a request IT can action and one that bounces back.

Ask for a TLS-inspection bypass, not just an allow rule. Allowlisting the domain while still inspecting the traffic frequently leaves this error in place, because the appliance is still rewriting the response. Ask for these domains to be added to the inspection exclusion list.

Send the block reference. Give your network team the vendor reference ID from the block page, the exact error text, and the timestamp. That lets them find the decision in their logs rather than guessing at a category.

Fix 2: Configure the proxy Copilot CLI actually reads

Copilot CLI is a Node application. It does not read Windows Internet Options, macOS network settings or your browser's proxy configuration — it reads environment variables. A machine where the browser works fine and Copilot CLI does not is usually this case.

export HTTPS_PROXY="http://proxy.company.com:8080"
export HTTP_PROXY="http://proxy.company.com:8080"
export NO_PROXY="localhost,127.0.0.1,.company.internal"

$env:HTTPS_PROXY = "http://proxy.company.com:8080"
$env:HTTP_PROXY  = "http://proxy.company.com:8080"

Add them to your shell profile so they survive a new terminal. If the proxy requires authentication, include credentials in the URL and be aware they are then visible in your environment:

export HTTPS_PROXY="http://user:password@proxy.company.com:8080"

URL-encode any special characters in the password — a raw @ or : will silently truncate the host and produce a confusing connection error instead of this one.

To find the proxy your browser is using, read the PAC file or policy your organisation deploys; on Windows, netsh winhttp show proxy reports the system-wide setting.

Fix 3: Trust the inspection CA properly

If TLS inspection is in use and cannot be bypassed, Node has to trust the appliance's CA. Export the root certificate your browser shows for github.com in PEM format, then:

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

$env:NODE_EXTRA_CA_CERTS = "C:\certs\corporate-ca.pem"

Point this at the root CA, not at the leaf certificate for github.com, and include intermediates in the file if your organisation uses them.

Do not reach for NODE_TLS_REJECT_UNAUTHORIZED=0. It suppresses certificate validation for every connection the process makes, which removes the only mechanism that would tell you about a genuine attack, and it does not reliably fix this error anyway — a proxy returning a block page will keep returning it whether or not you validate its certificate.

Fix 4: Rule your network out entirely

The definitive test takes two minutes:

# Tether to a phone, then:
copilot --version

If Copilot CLI works on a mobile hotspot and fails on the corporate network, the diagnosis is settled: the network is intercepting the traffic and no amount of reinstalling, re-authenticating or clearing caches will change it. Take that result to your IT team — it is much harder to dispute than a description of the error.

If it fails on the hotspot too, the problem is not interception. Check GitHub's status at githubstatus.com and re-authenticate:

copilot auth status
copilot auth login

Why the status code varies

403 and 503 come from the same mechanism and need the same fix. What differs is only what the intercepting device chose to send:

• 403 — a policy denied the request outright, usually by destination or content category. Expect a named category in the block page.
• 503 — the appliance tried and could not complete the request: an upstream filtering service was unreachable, a licence check failed, or the device was overloaded. These often look intermittent, which is why people mistake them for a GitHub outage.

Either way, Copilot CLI never spoke to GitHub. Diagnose the middlebox, not the service.

Related guides

• How to fix Copilot CLI proxy issues — the full corporate-network setup: authenticated proxies, NTLM and Kerberos, certificate chains and Git proxy configuration
• Copilot: permission denied and could not request permission from user — a failure that looks similar but happens after the connection succeeds
• Forbidden: unauthorized, not licensed to use Copilot — when GitHub does answer, and refuses