[BUG] Custom network egress policy blocks 3rd custom domain (exact and wildcard) while earlier entries on the same list work

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?

Summary

On a cloud routine (CCR) environment configured with Network access: Custom, the first two entries in the "Allowed domains" list resolve correctly, but a third custom domain is consistently denied by the egress proxy — both as an exact hostname and as a wildcard — while the first two entries keep working in the exact same runs. This looks like a bug in how the Custom allowlist is applied/propagated for cloud environments, rather than a configuration mistake on our side (we've verified the setting is saved correctly, retyped it, tried a wildcard, and waited well over the length of several runs for propagation).

Environment

• Environment: "Default", id env_01JhWY4hjEd2E5bB8rRTEtUZ
• Network access mode: Custom
• Allowed domains configured (in this order):

1. login.microsoftonline.com
2. graph.microsoft.com
3. office.ltl-developments.nl — later changed to *.ltl-developments.nl

• "Also include default list of common package managers" — checked
• Routine: "Inkoopfacturen verwerken - dagelijks", id trig_01J1vpmRbYJv7hNKZVKxxYTU
• Account: Team plan, organization account

Expected behavior

All three configured domains (entries 1, 2, and 3) should be reachable from within the routine's sandboxed session, since they're all present in the same "Allowed domains" list of the same environment.

Actual behavior

Across 4 separate routine runs (fresh sandbox each time):

• login.microsoftonline.com (entry 1): consistently reachable — 302 on every run.
• graph.microsoft.com (entry 2): consistently reachable — 200 on every run.
• office.ltl-developments.nl (entry 3, exact hostname): always denied.
• *.ltl-developments.nl (entry 3, changed to wildcard, same underlying host): always denied, identical failure signature.

Error signature seen in-session (curl through the session's $HTTPS_PROXY):

curl: (56) CONNECT tunnel failed, response 403

(In an earlier run, before the domain was first added to the allowlist, the same host returned response 502 instead of 403 — i.e. the failure mode itself changed once the domain was added to the Custom list, but access was still denied.)

Confirmed this is a policy denial, not a transient network issue or an issue with the destination server, via:

• curl "$HTTPS_PROXY/__agentproxy/status" inside the session — reports the proxy as enabled: true and correctly running.
• /root/.ccr/README.md inside the session — documents that $HTTPS_PROXY "tunnels to a policy-enforcing egress proxy" that returns denials for non-allowed destinations.
• The exact same host (office.ltl-developments.nl / *.ltl-developments.nl) was tested with plain curl -v, with a Microsoft Graph API call to a completely different, definitely-reachable host (graph.microsoft.com) succeeding in the same session at the same time — ruling out a general network outage.

Steps to reproduce

1. Create (or edit) a cloud environment with Network access: Custom.
2. Add at least 3 domains to "Allowed domains", e.g.:

``
login.microsoftonline.com
graph.microsoft.com
<your-third-domain>
``

1. Save.
2. Run a routine using that environment.
3. From within the session, curl all three domains.
4. Observe: domains 1 and 2 succeed; domain 3 fails with curl: (56) CONNECT tunnel failed, response 403 (or 502 if the domain was only just added).
5. Remove and re-add the third domain (exact retype) — same failure.
6. Replace the third domain with a wildcard (*.<domain>) — same failure, same error.

What we already tried (all unsuccessful)

• Re-typing the domain from scratch (delete the line, save, re-add, save) — no change.
• Switching from the exact hostname to a wildcard pattern (*.ltl-developments.nl) — no change, identical error.
• Waited well over 30+ minutes and multiple fresh routine runs between attempts to rule out a propagation-delay/caching issue.
• Confirmed the other two domains on the exact same list work correctly in every single run, in the same session, at almost the same timestamp as the failing request — ruling out a general environment/network problem.

Additional context

The destination in this case is a self-hosted service on a VPS (office.ltl-developments.nl, hyphenated domain, standard HTTPS on port 443, fronted by Caddy with a normal Let's Encrypt certificate) — not behind Cloudflare or any other WAF/anti-bot layer that would explain a host-side block, and there is no evidence in the routine's own diagnostics that the request even reached the destination server (the 403 comes from $HTTPS_PROXY itself, before the CONNECT tunnel is established).

Happy to provide the routine ID / environment ID / run session IDs to Anthropic support/engineering directly if useful for debugging on your end (not included here to avoid pasting internal identifiers into a public issue unnecessarily).

What Should Happen?

All three configured domains (entries 1, 2, and 3) should be reachable from within the routine's sandboxed session, since they're all present in the same "Allowed domains" list of the same environment.

Error Messages/Logs

Steps to Reproduce

1. Create (or edit) a cloud environment with Network access: Custom.
2. Add at least 3 domains to "Allowed domains", e.g.:

login.microsoftonline.com
graph.microsoft.com
<your-third-domain>

1. Save.
2. Run a routine using that environment.
3. From within the session, curl all three domains.
4. Observe: domains 1 and 2 succeed; domain 3 fails with curl: (56) CONNECT tunnel failed, response 403 (or 502 if the domain was only just added).
5. Remove and re-add the third domain (exact retype) — same failure.
6. Replace the third domain with a wildcard (*.<domain>) — same failure, same error.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — reporting a bug in the claude.ai/code web/cloud routines feature, not the local CLI. No local Claude Code CLI installed.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_