Built-in web_fetch does not work with HTTP proxies

[JoergStrebel]

Describe the bug

I am running GH Copilot on WSL in a corporate environment and I cannot get the /research command or a simple prompted Web URL retrieval to work in GH Copilot CLI. It looks very much like GH Copilot CLI does not support mandatory HTTP proxies for Web access

> Please retrieve the URL https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
Fetching web content https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html · url: "https://maven.apache.org/guides/introduction/introduction-to…" TypeError: fetch failed
Fetch failed (network error / TypeError, possibly unreachable from this environment). Want me to retry, or try an alternate source (e.g., cached/mirrored version)?
> You should be able to access the URL via the http proxy settings in the environment.
Thought for 1s
Fetching web content https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html · url: "https://maven.apache.org/guides/introduction/introduction-to…" TypeError: fetch failed
Thought for 1s
Shell Check proxy env vars and fetch URL via curl 11 lines…
env | grep -i proxy; echo "---"; curl -sS -m 20 -o /tmp/maven.html -w "HTTP:%{http_code}\n" https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
Proxy env vars were set, and  curl  retrieved it successfully (HTTP 200). 
Successfully retrieved the page via curl (proxy env vars worked; the  web_fetch  tool itself doesn't honor them). Summary of the page — "Introduction to the Build Lifecycle" (Maven docs):

Copilot CLI can access the Web via curl but not via its built-in web_fetch tool.
Does anybody have an idea how to fix it?

Affected version

GitHub Copilot CLI 1.0.68.

Steps to reproduce the behavior

1. Ask Github Copilot to retrieve any public URL from the Internet
2. See how Copilot fails to retrieve it

Error message:
Fetching web content https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html · url: "https://maven.apache.org/guides/introduction/introduction-to…" TypeError: fetch failed
Fetch failed (network error / TypeError, possibly unreachable from this environment). Want me to retry, or try an alternate source (e.g., cached/mirrored version)?

Expected behavior

Internal tool web_fetch should honour existing HTTP proxy variables from the environment.

Additional context

• Operating system: WSL2 on MS Windows 11
• CPU architecture: x86_64
• Terminal emulator: Windows Terminal
• Shell: bash

[JoergStrebel]

Probably the same issue as #3948

[jdsika]

Root cause + a one-line fix for maintainers, plus a working local workaround. Same environment class (corporate proxy, Windows; also reproduces on WSL as OP shows). Almost certainly the same underlying bug as #3948.

Root cause

web_fetch fails while curl, the model/API calls, and sign-in all succeed — because they use different HTTP paths:

• The API client (models, auth, MCP over HTTP) uses @actions/http-client, which reads HTTP_PROXY/HTTPS_PROXY/NO_PROXY and builds a proxy agent. → works behind a proxy.
• web_fetch uses the global fetch() (undici) with no dispatcher set, so it always connects directly. Behind a mandatory proxy the direct connect is dropped → UND_ERR_CONNECT_TIMEOUT, surfaced as TypeError: fetch failed.

The CLI is distributed as a Node.js Single Executable Application (SEA). I verified on 1.0.68 (Windows, Node 24.16 bundled) that the SEA:

1. ignores NODE_OPTIONS — a --require preload that wraps globalThis.fetch never runs inside copilot.exe (it runs in the npm-loader node.exe, but not in the SEA that actually performs the fetch). Confirmed by process-env inspection: NODE_OPTIONS is present in the SEA process env, but has no effect.
2. ignores NODE_USE_ENV_PROXY=1 for its global fetch() (the Node ≥24.5 flag that would otherwise make the built-in fetch honor HTTP(S)_PROXY). The same flag works correctly in a plain node on the same machine, so this is SEA-specific.

Net: there is currently no environment variable a user can set to make web_fetch honor a proxy, even though the docs advertise HTTP_PROXY/HTTPS_PROXY/NO_PROXY support.

Minimal confirmation

# same shell, same proxy env:
curl -sS -I https://www.w3.org/TR/shacl/        # HTTP/1.1 200 (via proxy)
node -e "fetch('https://www.w3.org/TR/shacl/',{method:'HEAD'}).then(r=>console.log(r.status)).catch(e=>console.log(e.cause?.code))"
#   -> UND_ERR_CONNECT_TIMEOUT   (Node's global fetch ignores the proxy by default)

NODE_USE_ENV_PROXY=1 node -e "fetch('https://www.w3.org/TR/shacl/',{method:'HEAD'}).then(r=>console.log(r.status))"
#   -> 200   (works in plain node… but the SEA ignores this flag)

Suggested fix (one line, undici is already bundled)

At startup, when a proxy env var is set, install a proxy dispatcher for the global fetch:

import { setGlobalDispatcher, EnvHttpProxyAgent } from "undici";
if (process.env.HTTPS_PROXY || process.env.HTTP_PROXY ||
    process.env.https_proxy || process.env.http_proxy) {
  setGlobalDispatcher(new EnvHttpProxyAgent()); // honors HTTP(S)_PROXY + NO_PROXY
}

EnvHttpProxyAgent reads HTTP_PROXY/HTTPS_PROXY/NO_PROXY itself, so this also fixes web_search//research and any other global-fetch call behind a proxy, and respects NO_PROXY for internal hosts. (Doing it unconditionally is fine too — with no proxy env set it's a no-op.)

I verified this exact snippet makes the SEA's web_fetch work through the proxy (see workaround below).

Workaround for affected users (temporary — until this is fixed upstream)

The SEA loads its real app code (app.js) from disk — the highest-version copy under the package cache, e.g. on Windows:
%LOCALAPPDATA%\copilot\pkg\<platform>-<arch>\<version>\app.js
(on macOS/Linux: ~/Library/Caches/copilot/pkg/... or ~/.cache/copilot/pkg/...).

Prepending the snippet above to the top of that app.js (after the #!/usr/bin/env node shebang) makes web_fetch honor the proxy — because that code runs inside the SEA process where the fetch happens. undici is resolvable from the globally-installed CLI's node_modules (or npm i -g undici).

Caveats: this is a local patch to a generated file, so it must be re-applied after every copilot update (a new version dir is created unpatched), and it's obviously not a substitute for the upstream fix. Restart the CLI after patching.

Happy to provide the exact process/binary diagnostics (SEA NODE_SEA_BLOB/fuse markers, process-env dumps, the COPILOT_RUN_APP=1 child that imports app.js) if useful.