[BUG] Claude Code on the web: `us.sentry.io` blocked under Trusted egress (403 `host_not_allowed`) — `*.sentry.io` missing from the enforced allowlist despite being a documented Trusted default

[qtipbera]

Preflight Checklist

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

What's Wrong?

On Claude Code on the web with an environment set to Trusted network access, outbound requests to us.sentry.io are blocked at the egress proxy with HTTP 403 / x-deny-reason: host_not_allowed. The request never reaches Sentry.

This contradicts the documented Trusted defaults: sentry.io, *.sentry.io, and downloads.sentry-cdn.com are all listed as Trusted default allowed domains under "Cloud services and monitoring" at https://code.claude.com/docs/en/claude-code-on-the-web. The behavior worked previously and began failing in early June 2026 — i.e. a regression.

A scope check from the same session shows the block is Sentry-specific, not a broad egress outage. Other hosts in the same Trusted "Cloud services and monitoring" group are reachable (Datadog, Honeycomb), as are GitHub and PyPI. Only Sentry is blocked.

The pattern (apex behaving differently from subdomains) suggests the *.sentry.io wildcard was dropped from the enforced Trusted allowlist while the bare sentry.io apex was retained — a bare-apex entry does not match the us.sentry.io subdomain.

What Should Happen?

Per the documented Trusted default allowlist, a Trusted environment should reach sentry.io and any *.sentry.io subdomain, so us.sentry.io (the US-region Sentry API host) should respond normally rather than returning 403 host_not_allowed.

Error Messages/Logs

Observed from a fresh Trusted session:

$ curl -sv https://us.sentry.io/api/0/ 2>&1 | grep -iE 'x-deny-reason|< HTTP'
< HTTP/1.1 403 Forbidden
< x-deny-reason: host_not_allowed
< server: envoy

# Control hosts in the SAME Trusted "Cloud services and monitoring" group — reachable:
$ curl -sv https://api.datadoghq.com/ 2>&1 | grep -iE 'x-deny-reason|< HTTP'
< HTTP/1.1 307 Temporary Redirect
$ curl -sv https://api.honeycomb.io/ 2>&1 | grep -iE 'x-deny-reason|< HTTP'
< HTTP/1.1 200 OK

# Other Trusted defaults — reachable (no host_not_allowed):
$ curl -sv https://api.github.com/ 2>&1 | grep -iE '< HTTP'
$ curl -sv https://pypi.org/ 2>&1 | grep -iE '< HTTP'

Apex-vs-subdomain check (run this to confirm the dropped-wildcard hypothesis):

$ curl -sv https://sentry.io/          2>&1 | grep -iE 'x-deny-reason|< HTTP'   # apex
$ curl -sv https://us.sentry.io/api/0/ 2>&1 | grep -iE 'x-deny-reason|< HTTP'   # subdomain → 403 host_not_allowed

If the apex is reachable while the subdomain returns host_not_allowed, that confirms the wildcard was dropped and the apex retained.

Error Messages/Logs

Steps to Reproduce

1. Create or edit a Claude Code on the web environment with Network access = Trusted.
2. Start a session in that environment.
3. Run: curl -sv https://us.sentry.io/api/0/ 2>&1 | grep -iE 'x-deny-reason|< HTTP'
4. Observe HTTP 403 with x-deny-reason: host_not_allowed.
5. Confirm it is Sentry-specific by hitting api.datadoghq.com and api.honeycomb.io (same Trusted group) — both reachable.

Is this a regression?

Yes.

Last Working Version

Worked until approximately early June 2026 (exact date unknown).

Supporting evidence that *.sentry.io was an enforced default, not just documented

• The egress-control JWT captured in [BUG] Allow network egress - All domains' setting not reflected in session proxy JWT #34690 (2026-03-15) lists *.sentry.io in wildcard_entries.
• Claude-3p + Bedrock: managed-settings allowedDomains not honored, sandbox pinned to 4 hosts #56959 (2026-05-07) shows *.sentry.io and *.ingest.us.sentry.io among the mandatory injected hosts.
• The docs still list sentry.io and *.sentry.io as Trusted defaults as of 2026-06-09.
• No changelog entry around early June 2026 removes Sentry.

Impact

Breaks any Trusted-network workflow that reaches Sentry — for example a scheduled routine that reads and triages recent Sentry issues with a read-only token. Because the documented default and the enforced allowlist disagree, environments configured exactly per the docs fail with no indication that anything is misconfigured on the user side.

Request

Restore *.sentry.io to the enforced Trusted allowlist so it matches the documented default, and confirm downloads.sentry-cdn.com and the ingest subdomains (*.ingest.us.sentry.io / *.ingest.sentry.io) are covered.

Claude Model

N/A (network egress, model-independent)

Platform

Claude Code on the Web

Operating System

N/A (Anthropic-managed cloud environment)

Additional Information

Related issues: #34690 ("All domains" not reflected in the egress JWT; contains the March-15 JWT showing *.sentry.io), #51400 (additional-domain entries not enforced; wildcard matching inconsistent), #19087 (custom domains not applied to container egress).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.141 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.