Claude Code web sandbox proxy allowlist blocks user-owned custom domains
Summary
Every new Claude Code web session spins up a fresh sandbox with an Anthropic-managed proxy allowlist. User-owned custom domains (including subdomains of domains the user demonstrably controls, like cc.tacticalmarketingpro.com) are not on the allowlist, which breaks any workflow where the session needs to reach the user's own hosted tooling.
Repro
- Open a new Claude Code web session (claude.ai/code or equivalent)
- Have the session attempt to reach a user-owned domain, for example via the Chrome browser tool: navigate to
https://cc.tacticalmarketingpro.com - Network request fails at the sandbox proxy layer (not at DNS, not at the remote server — the request never leaves the sandbox)
Expected: the request reaches the user's own domain.
Actual: the request is blocked by the proxy.
Impact
In my workflow, this affects a "Start Connection" protocol that fetches current project state from a self-hosted dashboard at cc.tacticalmarketingpro.com. Every new session has to use a workaround path (SSH into the VM and curl localhost instead) which:
- Adds friction to every session start
- Isn't discoverable — new users would just see "navigate failed" without understanding why
- Silently blocks an entire class of workflows (any user-hosted internal tooling)
Two possible fixes
Short-term (unblocks me specifically):
Add cc.tacticalmarketingpro.com to the web sandbox allowlist.
Long-term (fixes the category):
Let users declare additional allowlisted domains at the project or session level — for example, a setting in ~/.claude/settings.json or a per-project .claude/allowed-hosts.json that extends the default allowlist with user-owned domains. Happy to help spec this if useful.
Workaround I currently use
SSH to the VM that hosts my dashboard and curl localhost instead of hitting the public URL. Works, but every new session has to remember to take this path, and it only covers the "read state" case — anything that actually needs the public URL (webhooks, OAuth callbacks, UI verification) still breaks.
Environment
- Claude Code web (every new session reproduces)
- User-owned domain:
cc.tacticalmarketingpro.com - DNS and TLS both work correctly from outside the sandbox (site is reachable on the public internet)
Related
- #52543 — similar shape, specific-domain allowlist addition for web sandbox (readwise.io, podwise.ai)
- #41565 — configurable allowlist, but scoped to remote triggers
- #41741 — WebFetch blocked by egress proxy for custom domains (related root cause)
Happy to provide more detail if helpful.
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Additional evidence (second session, different repo, same sandbox behavior)
Just reproduced this from a separate Claude Code web session (courseos repo, different sandbox instance) with more specific error text:
The "DNS cache overflow" response is the actual proxy error — that may be more actionable for triage than my original "request never leaves the sandbox" framing. It's the egress proxy rejecting the host, not a DNS or remote-server issue.
Two additional notes that matter for the fix propagation story
cc.tacticalmarketingpro.com/mcp. When the allowlist blocks that host, the MCP tools don't register at boot, andToolSearchfor my cc_* / jarvis tools returns "No matching deferred tools found." So this isn't just about HTTPS navigation via the Chrome tool — it cascades into the whole MCP subsystem failing to register any tools from user-owned endpoints.Full picture: the allowlist gap breaks both (a) direct navigation/HTTP to the user's domain and (b) any MCP servers hosted on it. Project/session-level allowlist config would fix both classes at once.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Adding a concrete public-service use case, hoping this can be reconsidered.
Environment: Claude Code Cowork (cloud/managed sandbox), Windows desktop app.
The sandbox proxy blocks gis.ktimanet.gr — the official Greek national land-registry (Ktimatologio) map viewer — with 403 Forbidden. This is a public, read-only government endpoint used to resolve coordinates → KAEK (cadastral code).
Setting sandbox.network.allowedDomains in project .claude/settings.local.json has no effect here: I added the domain, restarted, still 403. So in this managed environment the local allowlist is silently ignored and there is no user-facing way to permit an outbound domain.
Same skill works perfectly from a local Claude Code session (open network) — it only fails inside the Cowork cloud sandbox because of the fixed proxy allowlist.
Request: a user- or org-configurable outbound allowlist for cloud/Cowork sandboxes — e.g. honor sandbox.network.allowedDomains from user/managed settings, a per-project allowed-hosts file, or an entry in the claude.ai admin console. Even an opt-in, per-project confirmation prompt would unblock legitimate workflows like this one.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.