### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Hi, I've hit a third variant of this issue today, so I asked Opus to write a thorough report pasted below. I've reviewed the report for overall correctnes

[BUG] Code on the web: Trusted egress allowlist is systematically out of sync with where tooling connects

Open 💬 0 comments Opened Jun 26, 2026 by matrach

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Hi,
I've hit a third variant of this issue today, so I asked Opus to write a thorough report pasted below. I've reviewed the report for overall correctness.
Best Regards,
matrach

[!NOTE] All the content below was _generated by Claude Code_ — session

Under Trusted network access on Claude Code on the web, the default
allowed domains
repeatedly list a legacy or sibling host while the tooling connects to a
different host that is not allowlisted. The egress proxy then answers 403 to
the CONNECT, and the operation fails. This is not one typo; it is the same
defect in several places, which points at a missing validation step: the
allowlist is not checked against the hosts the bundled toolchains (and the base
image's own apt sources / pre-configured registries) actually reach.

| Area | Allowlist contains (looks right) | Tool actually fetches from (omitted → 403) | Status |
| --- | --- | --- | --- |
| Docker CDN | production.cloudflare.docker.com | production.cloudfront.docker.com | filed: #69174 |
| .NET SDK | dotnet.microsoft.com | builds.dotnet.microsoft.com, dotnetcli.azureedge.net, download.visualstudio.microsoft.com | filed: #11897 |
| Launchpad PPAs | ppa.launchpad.net (legacy) | ppa.launchpadcontent.net (current) | this report |
| GHCR | ghcr.io (front) | pkg-containers.githubusercontent.com (blobs) | this report |
| ECR Public | public.ecr.aws (front) | *.cloudfront.net (blobs) | this report |
| Kubernetes registry | k8s.io, dl.k8s.io, pkgs.k8s.io | registry.k8s.io (the image registry) | this report |

Instance 1 — Launchpad PPAs (apt)

Launchpad serves PPA index/pool files from ppa.launchpadcontent.net; the older
ppa.launchpad.net name is legacy. The Trusted allowlist lists
ppa.launchpad.net, launchpad.net, and www.launchpad.net — but not
ppa.launchpadcontent.net, so every PPA is unreachable. The base image (Ubuntu
24.04 "noble") ships two PPA sources enabled by default, both on the blocked
host:

/etc/apt/sources.list.d/deadsnakes-ubuntu-ppa-noble.sources  → ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu/
/etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources      → ppa.launchpadcontent.net/ondrej/php/ubuntu/

apt-get update reports the blocked PPA as a warning and still exits 0, so
the breakage is silent until an apt-get install resolves a package — or a
dependency's candidate version — to the PPA, at which point the install aborts
mid-download.

Instance 2 — Container registries: the front is allowlisted, the blob CDN is not

An image pull is two hops: resolve the manifest from the registry front, then
download layer blobs from a separate CDN/storage host. The allowlist covers
the fronts but omits several blob hosts, so the registry authenticates and then
fails mid-pull. Verified with real docker pull in this Trusted session:

| Registry | Manifest host (allowlisted) | Blob/layer host | Pull result |
| --- | --- | --- | --- |
| Docker Hub | registry-1.docker.io ✓ | production.cloudfront.docker.com | ✓ in this session [†](#footnote), but cloudfront is not in the defaults (#69174); a plain Trusted session fails the blob download |
| GCR | gcr.io ✓ | storage.googleapis.com ✓ | ✓ full pull |
| MCR | mcr.microsoft.com ✓ | *.data.mcr.microsoft.com ✓ | ✓ full pull |
| GHCR | ghcr.io ✓ | pkg-containers.githubusercontent.com ✗ 403 | ✗ blob download Forbidden |
| ECR Public | public.ecr.aws ✓ | *.cloudfront.net ✗ 403 | ✗ blob download Forbidden |
| registry.k8s.io | registry.k8s.io ✗ 403 | — | ✗ manifest Forbidden; host not in the list at all |

<a id="footnote"></a>† This session used Custom network access with "Also
include default list
of common package managers" checked, plus extra Docker hosts — including
production.cloudfront.docker.com. That custom addition, not the Trusted
defaults, is why Docker Hub's blob CDN resolved here; on a plain Trusted session
the Hub blob download would 403 (this is #69174). The GHCR / ECR Public /
registry.k8s.io failures occur regardless of the custom entries.

registry.k8s.io is the canonical Kubernetes image registry since the 2023
k8s.gcr.io retirement, yet only k8s.io/dl.k8s.io/pkgs.k8s.io are listed.

What Should Happen?

Under Trusted, the operations the docs imply are supported should succeed:
apt install from the base image's pre-configured PPAs, and docker pull from
the listed registries (GHCR, ECR Public) and from the canonical
registry.k8s.io — without 403s. More generally, the allowlist should cover the
operational hosts the bundled toolchains actually dial (CDN edges, redirect
targets, renamed file hosts), not only the human-plausible apex/legacy names.

Error Messages/Logs

# apt — base-image deadsnakes PPA, Trusted session
$ apt-get update -qq
W: Failed to fetch https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu/dists/noble/InRelease
   Invalid response from proxy: HTTP/1.1 403 Forbidden
$ apt-get install -y python3.14        # candidate 3.14.3-1+noble1 is from deadsnakes
E: Failed to fetch https://ppa.launchpadcontent.net/.../python3.14_3.14.3-1+noble1_amd64.deb
   Invalid response from proxy: HTTP/1.1 403 Forbidden
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

# docker pull ghcr.io/distroless/static — manifest OK, layer 403
failed to copy: httpReadSeeker: failed open: failed to do request:
Get "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:…": Forbidden

# docker pull registry.k8s.io/pause:3.9 — blocked at the manifest
Error response from daemon: failed to resolve reference "registry.k8s.io/pause:3.9":
Head "https://registry.k8s.io/v2/pause/manifests/3.9": Forbidden

# docker pull public.ecr.aws/docker/library/alpine — manifest OK, layer 403 from CloudFront
failed to copy: httpReadSeeker: failed open: …
Get "https://d2glxqk2uabbnd.cloudfront.net/v2/…": Forbidden

# The egress proxy logs each as a policy denial on the host (not an origin error):
connect_rejected: gateway answered 403 to CONNECT (policy denial or upstream failure)
                  host=ppa.launchpadcontent.net:443
connect_rejected: … host=pkg-containers.githubusercontent.com:443
connect_rejected: … host=registry.k8s.io:443

Steps to Reproduce

On a Claude Code on the web session with Trusted network access (the
default), in the sandbox shell. (If you are a human working on this, you can't drive
the sandbox directly — ask the model to run these in a session and paste the
output, especially step 5.)

Launchpad/PPA (uses the base image's own sources):

``bash apt-get update # 403 warnings for ppa.launchpadcontent.net (deadsnakes, ondrej) apt-get install -y python3.14 # aborts: 403 fetching the .deb from ppa.launchpadcontent.net``

GHCR blob host blocked:

``bash docker pull ghcr.io/distroless/static:latest # auths, then 403 on pkg-containers.githubusercontent.com``

registry.k8s.io fully blocked:

``bash docker pull registry.k8s.io/pause:3.9 # 403 on the manifest HEAD``

ECR Public blob CDN blocked:

``bash docker pull public.ecr.aws/docker/library/alpine:latest # auths, then 403 on *.cloudfront.net``

Confirm it is policy, not origin: curl -sS "$HTTPS_PROXY/__agentproxy/status"

and read recentRelayFailures — the blocked hosts appear as
connect_rejected: gateway answered 403 to CONNECT. (A dead origin shows
502/000 instead — e.g. cdn-lfs.huggingface.co is a decommissioned host,
not an allowlist gap; that distinction is how a real allowlist bug is told
apart from a stale hostname.)

Control: apt-get install -y poppler-utils and docker pull hello-world
(Docker Hub) succeed, so the network path is fine — only specific hostnames are
wrong/missing in the allowlist.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.193 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Dropdown-field detail. Platform: Claude Code on the web — an

Anthropic-managed cloud sandbox on the Anthropic API — which the Platform
dropdown has no option for, hence Other. Operating System: Ubuntu
24.04.4 LTS (sandbox VM, kernel Linux 6.18.5). Terminal/Shell: the
cloud-session Bash tool shell (non-interactive) inside the web sandbox, so
Other. Network access is Trusted; outbound traffic transits the
sandbox egress proxy.

Why "it never worked": this is a standing gap between the published

Trusted allowlist and the hosts the bundled tooling / base image use, not a
version regression — #69174 and #11897 report the same class against earlier
builds, so it has persisted across versions.

Method note: classification relies on the proxy's recentRelayFailures

(connect_rejected = policy 403 to CONNECT) versus 502/000 (dead
origin/DNS), not on curl exit codes alone, to avoid mislabeling a
decommissioned host as an allowlist gap.

Caveat on #69174 (see the † footnote above):

production.cloudfront.docker.com resolved only because this session's Custom
allowlist added it; a default Trusted session blocks it. The GHCR / ECR
Public / registry.k8s.io failures are independent of any custom entries.

Requested fix

Add the missing operational hosts to the Trusted defaults:

ppa.launchpadcontent.net (and consider *.launchpadcontent.net)
production.cloudfront.docker.com (per #69174)
the .NET binary hosts in #11897
pkg-containers.githubusercontent.com (GHCR blob host)
registry.k8s.io (canonical Kubernetes image registry)
a blob CDN host for ECR Public — its layers come from a *.cloudfront.net

distribution, which *.amazonaws.com does not cover

Treat the allowlist as derived from where the bundled toolchains and the base

image's package sources/registries actually connect, and add a check that
fails CI when a pre-installed source/CDN host is absent from the Trusted list,
so this class of drift is caught before release.

Consider dropping or redirecting the legacy ppa.launchpad.net and the

wrong production.cloudflare.docker.com entries, which imply support that
does not exist.

Cross-references

#69174 — Docker CDN host: production.cloudflare.docker.com vs production.cloudfront.docker.com.
#11897 — .NET SDK binary downloads blocked despite permissive network access.

View original on GitHub ↗