claude-code - 💡(How to fix) Fix Claude Code web sandbox proxy allowlist blocks user-owned custom domains [2 comments, 2 participants]

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

1. Open a new Claude Code web session (claude.ai/code or equivalent)
2. Have the session attempt to reach a user-owned domain, for example via the Chrome browser tool: navigate to https://cc.tacticalmarketingpro.com
3. 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.