GitHub Copilot CLI Sandbox Proxy: Route Host-Rule Traffic Through HTTPS_PROXY After 1.0.100

You enable the sandbox in GitHub Copilot CLI, add a host rule for your corporate Artifactory mirror, ask the agent to install one package, and the command hangs until it dies with a connection timeout or a certificate error. Outside the sandbox the same install works. Inside it, nothing moves. On corporate laptops this was not a bug in your host rules; it was the sandbox ignoring your egress proxy. The GitHub Copilot CLI sandbox proxy behavior changed in 1.0.100-1, released 2026-10-16, and this guide is the afternoon runbook for using that change: reproduce the old failure, export the right variables, verify the proxy actually carried the traffic, and keep an egress worksheet your team can reuse on every host rule.

This is a Playbooks guide for a developer or platform engineer inside a corporate network with an egress proxy or TLS-inspecting firewall. You need Copilot CLI 1.0.100 or newer (1.0.100-1 is marked prerelease on the release page), your corporate HTTPS_PROXY/HTTP_PROXY values, any NO_PROXY exceptions for internal hosts, and a repo where the sandbox permits specific host rules. Every command and expected observation below is labeled as either verified release behavior or standard environment behavior you should confirm on your own machine; I ran none of these on your network, so treat the outputs as what to look for, not as results I observed.

What actually changed, and why it matters

The 1.0.100-1 release notes contain one Fixed line that is the entire reason this guide exists: “Sandbox host-rule traffic now honors HTTPS_PROXY and HTTP_PROXY when no sandbox proxy is configured” (release 1.0.100-1). Read it precisely, because the conditional clause is where operators trip:

1. Scope: host-rule traffic. The change covers network requests the sandbox makes to hosts you explicitly allowed through host rules — your registry mirror, your GitHub Enterprise instance, a documentation host you permitted.
2. Mechanism: environment variables. The carrier is HTTPS_PROXY and HTTP_PROXY, the standard environment variables — not a Copilot-specific setting file.
3. Condition: when no sandbox proxy is configured. If your organization already configures a sandbox-specific proxy, that configuration wins and the environment variables are the fallback path, not an override.

Before this release, a sandboxed command with a valid host rule could still attempt direct egress. On a network where direct egress to the internet is blocked and everything must transit the corporate proxy, “direct” means the packet goes nowhere: a hang, then a timeout, or — if a transparent TLS-inspecting firewall intercepts it — a certificate error from an unexpected CA. The host rule was honored; the network path was not. That gap is also why this failure looked so much like a misconfigured host rule and burned whole afternoons: every fix operators reached for first (wider rules, port changes, DNS checks) touched the allowlist when the allowlist was never the problem.

Two neighboring releases sharpen the picture. 1.0.100-0, shipped the same day at 20:10 UTC, added a prompt to update the sandbox proxy certificate authority when masked hosts change. The releases index shows 1.0.99-3 (16 Oct) making sandboxed shell commands explain credential-proxy certificate trust failures and offer an approved rerun outside the sandbox, and 1.0.99-2 (16 Oct) making catalog search report proxy authentication requirements for CONNECT proxy challenges. GitHub has been tightening the sandbox-to-proxy seam all week; 1.0.100-1 closes the biggest gap. If you want the harness landscape context, see the other American harnesses — this guide stays on the networking seam.

Reproduce the pre-1.0.100 failure on a host rule

Start by proving the failure mode on your machine, so that after the upgrade you can prove the fix with the same test. Use a throwaway branch or worktree so a half-completed install never touches your working tree.

1. Check your version. Run copilot --version (or the version flag your install supports). If it prints anything below 1.0.100, you are on the old behavior for host-rule egress. Record the exact string with the date — it goes in the worksheet later.
2. Keep the sandbox session-scoped. In the CLI, use /sandbox to keep sandboxing enabled for the current session without enabling it globally. The 1.0.99-0 release notes in the releases index describe this session-scoped option; use it so a failed experiment never leaks into your other sessions. This is the same discipline as treating permission modes as fleet policy rather than a per-chat setting.
3. Add a host rule for one corporate host. Permit exactly one internal mirror, for example your Artifactory or npm registry FQDN, and nothing else. One host keeps the diagnosis clean: if the failure reproduces, only one variable was in play.
4. Clear the proxy variables in the launching shell so the test reflects the old default path: env -u HTTPS_PROXY -u HTTP_PROXY -u NO_PROXY copilot on Linux/macOS, or remove them from your PowerShell session on Windows.
5. Ask the agent to run a package install that must reach that host — for example, npm install with your internal registry configured.
6. Record the failure observation with a timestamp. Expected shape on a blocked network: the install command stalls for the tool’s connect timeout (often tens of seconds to minutes), then exits with a socket timeout such as ETIMEDOUT/Connection timed out, or fails TLS with an unable to verify the first certificate / self-signed certificate in certificate chain error if a TLS-inspecting middlebox answered instead. Which of the two you see is diagnostic gold — record it verbatim.

A hang points to a firewall dropping direct egress; a certificate error points to a middlebox that answers it. Both were possible pre-1.0.100 symptoms of the same root cause: the sandboxed traffic never used your proxy. Label your captured output as your own observation — do not paste mine, because I did not run on your network.

Upgrade to 1.0.100-1 and export the proxy variables

Now change exactly two things: the CLI version and the proxy environment. Changing both at once is deliberate — this is the fix, not an experiment — but keep every other variable frozen so the before/after comparison stays honest.

1. Install the prerelease. The README documents the official channels: npm install -g @github/copilot@prerelease, brew install copilot-cli@prerelease, winget install GitHub.Copilot.Prerelease, or the install script with VERSION="v1.0.100-1". Use one channel consistently; mixing channels is how stale binaries end up earlier on PATH.
2. Verify the binary and the build. Re-run the version flag and confirm 1.0.100-1. If your security team wants artifact assurance, the release API record lists per-asset SHA-256 digests and a published SHA256SUMS.txt; you can check a downloaded archive against the digest before installing. That is standard supply-chain hygiene for any CLI you let run commands — the same instinct behind treating sandboxes as a suggestion, not a guarantee.
3. Export the proxy variables in the shell that launches copilot. Standard POSIX form (confirm the exact values with your network team):

export HTTPS_PROXY="http://proxy.corp.example:3128"
export HTTP_PROXY="http://proxy.corp.example:3128"
export NO_PROXY=".corp.example,localhost,127.0.0.1,artifactory.corp.example"
# Now confirm what the launching shell exports; expect the version line plus three proxy lines
copilot --version && env | grep -i '^https_proxy\|^http_proxy\|^no_proxy'
# Expected: install completes and proxy log shows CONNECT artifactory.corp.example:443 with a 200 tunnel status
npm install --registry=https://artifactory.corp.example/api/npm/npm-virtual/

PowerShell equivalents: $env:HTTPS_PROXY = "http://proxy.corp.example:3128" and so on. The variables must exist in the environment the CLI process inherits — exported in that shell, in the profile the terminal loads, or in the session-scoped environment your launcher provides. A variable set in another terminal window does nothing for the process you launch here. 4. Re-run the identical install test from the previous section: same session-scoped sandbox, same single host rule, same package. 5. Record the success observation. Expected shape on 1.0.100-1: the install proceeds and completes, with connect latency consistent with the proxy hop. The release notes state host-rule traffic now honors these variables when no sandbox proxy is configured — the observable consequence is that the previously hanging install finishes. 6. Get independent evidence from the proxy side. Ask your proxy or network team for the access-log line matching your test: your machine’s source IP, the CONNECT artifactory.corp.example:443 (or GET) request, a 200-series tunnel status, and a timestamp inside your test window. One log line converts “it seems to work” into evidence you can put in a ticket. If nobody can read the proxy log, a sandboxed curl -v against the same host through the same environment — watching it print Connected to proxy.corp.example — is your fallback indicator, clearly labeled as indirect.

The filled egress worksheet: host rules, variables, CAs, observations

This worksheet is the reusable artifact. Fill one row per host rule; the example rows below are a worked corporate case — replace the hostnames with yours, keep the columns. Keep it in the repo next to your sandbox policy so it survives team turnover, and treat an unfilled evidence cell as an open task rather than a blank to ignore.

Host rule	Path that must carry it	NO_PROXY?	CA the sandbox must trust	Expected observation	Evidence recorded
artifactory.corp.example:443	HTTPS_PROXY → proxy.corp.example:3128	No — external-facing mirror reached via proxy	Corporate inspection CA if the proxy re-signs TLS; internal root if it does not	Install completes; proxy log shows CONNECT artifactory.corp.example:443 200	Proxy log line 2026-10-18 10:12, ticket NET-4471
github.example-enterprise.com:443	HTTPS_PROXY → proxy.corp.example:3128	No	Corporate inspection CA	git fetch inside sandbox succeeds after auth prompt	(fill: run 2 date/time)
registry.npmjs.org:443	HTTPS_PROXY → proxy.corp.example:3128	No	Corporate inspection CA	Public packages resolve; throughput lower than direct (proxy hop)	(fill)
build.corp.example:8443	Direct (internal)	Yes — listed in NO_PROXY	Internal service CA	Direct connection, no proxy log entry for this host	(fill)
localhost, 127.0.0.1	Direct	Yes	n/a	Loopback always direct; local dev servers reachable	(fill)

Three columns deserve comment. The path column forces the decision the release made automatic: external-facing hosts ride HTTPS_PROXY; genuinely internal hosts should never detour through a proxy that cannot reach them — sending build.corp.example to an internet egress proxy usually fails outright and always adds a hop nobody audited. The CA column is where TLS-inspecting networks live or die — see the next section. The evidence column is what turns the worksheet from a plan into a record; an unfilled evidence cell means the row is unverified, and next quarter someone will re-derive the whole test from scratch if you leave it blank.

A note on the fourth row: the releases index shows 1.0.99-0 changed the sandbox to allow local network access by default, so loopback and private-network hosts are already on the direct path — your NO_PROXY entry documents the intent rather than creating it. Documenting intent still matters: when a colleague later adds a proxy variable to a shared launcher, the worksheet row is what stops them from wondering whether build.corp.example was supposed to ride the proxy.

Reading masked-host TLS failures and CA prompts

When a TLS-inspecting proxy re-signs traffic, the sandboxed process sees the inspector’s certificate, not the origin’s. That produces the second failure family, and the recent releases give you specific tools:

1. Read the error, not the symptom. self-signed certificate in certificate chain means the sandbox does not trust the inspection CA. hostname mismatch means the mask or rule points at the wrong name. Treat these as different diagnoses with different fixes; only the first is a trust problem.
2. Expect a CA prompt on host changes. 1.0.100-0 added a prompt to update the sandbox proxy certificate authority when masked hosts change. If that prompt appears after you edit host rules, answer it deliberately — it is the CLI telling you the trust set no longer matches the traffic.
3. Use the clearer trust-failure explanations. 1.0.99-3 (see the releases index) made sandboxed shell commands explain credential-proxy certificate trust failures and offer an approved rerun outside the sandbox. Treat that offer as a diagnostic escape hatch, not a habit: rerunning outside the sandbox to fix a CA problem widens blast radius and teaches the agent the wrong lesson.
4. Install the inspection CA where the sandbox looks for it. Get the corporate root CA from your security team over a channel you trust, place it per your platform’s standard trust location, and re-run the single-host test. Do not disable certificate verification to make an error disappear; that trades a solvable trust problem for a permanent one.

The chart below shows how the worksheet rows distribute across the two network paths — a quick visual check that your host inventory is split the way you intended, not an assertion about your traffic volumes.

Proxy precedence: sandbox proxy first, environment second

The release wording — “when no sandbox proxy is configured” — defines the precedence you must document for your team:

Situation	Which path carries host-rule traffic	Operator action
Organization configures a sandbox proxy	The configured sandbox proxy	Get its address and CA from the platform team; environment variables are not the control surface
No sandbox proxy, HTTPS_PROXY set	The environment-variable proxy (new in 1.0.100-1)	Export variables in the launching shell; verify with proxy log evidence
No sandbox proxy, no variables set	Direct egress attempt	Works only on networks that allow direct; this is the pre-1.0.100 failure mode
Proxy requires authentication	CONNECT challenge surfaces to the client	1.0.99-2 made catalog search report proxy authentication requirements; expect credential prompts and capture them in your worksheet

Write this precedence into the worksheet header, not into tribal memory. The most expensive version of this confusion is a team where one engineer sets HTTPS_PROXY for a Copilot CLI that an admin already configured with a sandbox proxy: the fix silently does nothing, the host rule gets widened in desperation, and the real answer — ask the platform team which path owns egress — never happens. If your enterprise already runs a dedicated egress control layer for agents, this precedence question is part of the larger pattern in the agent gateway as the control plane: decide once, centrally, which hop owns agent egress, then make the CLI configuration agree with it.

The unified Sessions browser and the 500-record discovery cap

The same release changes how you find old sessions, which matters when you are toggling sandbox settings across many accounts. Per the 1.0.100-1 notes:

1. /sessions, /session and /resume now open one unified Sessions browser by default, instead of separate surfaces.
2. Session browsing caps account discovery at 500 records.
3. Automatic refresh timing respects Retry-After hints, so a rate-limited account does not get hammered by refreshes.

Operator implications, as practical checks:

• If you support engineers across many org accounts, 500 records is a hard discovery ceiling — if a session is not appearing, the cause may be the cap, not a bug. Narrow the search rather than assuming loss.
• Retry-After respect means account-list refreshes will visibly pause after throttling instead of retrying in a loop; read a stalled-looking refresh as backoff, and wait it out before filing an issue.
• One browser means one set of keyboard habits to retrain; update your team’s internal cheat sheet once.

Troubleshooting ladder when the proxy path breaks

Work this ladder top to bottom; change one thing per rung and re-run the single-host test after each. The order is deliberate: cheapest and most common causes first, release-specific causes last.

1. Confirm the variables are visible to the CLI process, not just your interactive shell: env | grep -i proxy in the same terminal that launches copilot. A variable set in another window or a GUI-launched terminal is the most common miss.
2. Confirm the version is genuinely 1.0.100+. Multiple install channels can leave an old binary earlier on PATH.
3. Split the failure. Same host, same variables, curl -v outside the CLI: if curl also fails, the problem is proxy reachability or credentials, not Copilot CLI.
4. Classify the error. Timeout → path/firewall issue (step 3). Certificate error → CA trust issue (the masked-host section above). 407 Proxy Authentication Required → credentials; note 1.0.99-2’s proxy-authentication reporting in the releases index.
5. Check NO_PROXY overreach. An entry like .example.com silently excludes hosts you meant to proxy; the install bypasses the proxy and fails exactly like the pre-fix behavior.
6. Check host-rule spelling against the actual request host. A registry redirect from npm to a CDN host needs the CDN host permitted too, or the first permitted hop succeeds and the redirect dies.
7. Only then suspect the release. File the issue with your captured observations, version string, and proxy log line.

Version-pin your findings: this ladder is written against 1.0.100-1, and Copilot CLI iterates quickly — the releases index shows ten releases in the first sixteen days of October 2026. Canary every CLI upgrade the way the canary guide prescribes, so a future default change does not rediscover this failure for you.

Rollback: restore direct egress and pin the previous version

If the proxy path breaks something that worked, reverse in this order — cheapest first:

1. Unset the variables for the session to restore direct egress: env -u HTTPS_PROXY -u HTTP_PROXY copilot (or clear $env: variables in PowerShell). Direct egress works again wherever the network still allows it.
2. Re-scope the sandbox. End the session and start a new one without session-scoped sandboxing; never leave global sandbox settings as residue of a failed experiment.
3. Pin the previous CLI version if 1.0.100-1 itself is the regression: the README install script accepts VERSION="v1.0.98" (the current Latest, per the releases index), and npm/Homebrew support versioned installs the same way. Pinning a prerelease fleet is exactly the drift the upgrade-canary discipline exists to catch.
4. Keep the worksheet row for the failing host with its failure observation. A rollback without a recorded reason becomes next quarter’s mystery outage.

For fleet operators running this across a whole engineering org, the durable version of this runbook is the worksheet itself plus a scheduled review of host rules — the same weekly-inventory instinct as the MCP server inventory ritual, applied to egress. And if you are the person deciding how agents get network access across a Windows estate generally, the procurement-side checklist in corporate AI on a Windows PC is the companion piece: this guide fixes one CLI’s sandbox path; that one decides the policy all such paths must serve.

Sources

• Release 1.0.100-1 · github/copilot-cli (GitHub) — primary source: the HTTPS_PROXY/HTTP_PROXY host-rule fix, unified Sessions browser default, 500-record discovery cap, Retry-After handling.
• GitHub API release record for v1.0.100-1 — prerelease flag, published_at 2026-10-16T22:41:25Z, asset digests and SHA256SUMS.
• Release 1.0.100-0 · github/copilot-cli (GitHub) — sandbox proxy certificate-authority update prompt when masked hosts change.
• github/copilot-cli README (GitHub) — install channels, VERSION pinning, prerequisites, GH_TOKEN/GITHUB_TOKEN authentication.
• Releases · github/copilot-cli (GitHub) — 1.0.99-0 through 1.0.99-3 sandbox and proxy-adjacent fixes; 1.0.98 as current Latest.