Routine (CCR) sandbox ignores Settings > Capabilities > Allow network egress = 'All domains' — WebFetch/curl 403 EGRESS_BLOCKED for all external domains

Summary

A scheduled Routine (created via the RemoteTrigger/routines API, environment kind anthropic_cloud) has WebFetch and direct curl blocked (EGRESS_BLOCKED / 403 on the CONNECT tunnel) for every external domain tested, despite the account's Settings > Capabilities > "Allow network egress" being enabled with the domain allowlist set to "All domains" (confirmed via screenshot of the settings page immediately before the test run).

This looks like the same underlying issue as #34690, #30112, #51400 and #19087, but specifically reproduced on a Routine (scheduled trigger session), not an interactive Cowork session — so filing separately in case the routine code path is a distinct enforcement point from the ones already tracked.

Environment

• Environment: Default (kind: anthropic_cloud)
• Trigger type: scheduled Routine (cron_expression, daily), also reproduced via manual run
• Session context: allowed_tools: ["Bash","Read","Write","Edit","Glob","Grep","WebSearch","WebFetch"], model claude-sonnet-5
• MCP connectors attached: Google Drive, Apollo.io (both reachable — only generic internet egress is blocked)

Steps to reproduce

1. In account Settings > Capabilities, set "Allow network egress" to ON, domain allowlist = "All domains".
2. Create (or use an existing) Routine whose prompt calls WebFetch on a public news URL, or run curl in Bash against any external domain.
3. Trigger the routine (scheduled fire or manual run).
4. Observe: WebFetch returns {"error_type":"EGRESS_BLOCKED","domain":"<any domain>","message":"Access to <domain> is blocked by the network egress proxy."}. curl through $HTTPS_PROXY returns CONNECT tunnel failed, response 403.

Evidence

• Tested 30+ distinct domains across two separate runs on the same routine, including neutral/control domains (google.com, en.wikipedia.org, reuters.com, example.com, httpbin.org, news.ycombinator.com) — all blocked.
• curl -sS "$HTTPS_PROXY/__agentproxy/status" inside the sandbox shows a noProxy allowlist limited to anthropic.com, registry.npmjs.org, pypi.org, files.pythonhosted.org, index.crates.io, proxy.golang.org, private IP ranges, etc. — i.e. package-manager/infra domains only, no general internet — which contradicts the account-level "All domains" setting.
• Two run session IDs showing the identical failure pattern: cse_019Lcv934UAgJzisjMqwxWrJ (2026-08-18T12:04 UTC, scheduled fire) and cse_01QefDaT2zt2nWMqEB7sA2j1 (2026-08-18T15:17 UTC, manual run, triggered specifically to retest after confirming the Capabilities setting was already "All domains").
• MCP-based egress (Google Drive, Apollo.io) works fine in the same sessions — only the sandbox's own network egress proxy is affected.

Expected behavior

When account-level "Allow network egress" = "All domains", WebFetch and outbound HTTPS from the Routine's sandbox should be able to reach general internet domains, consistent with the setting shown in Settings > Capabilities.

Actual behavior

All non-allowlisted (non-infra) domains are rejected with 403 at the egress proxy, regardless of the account's Capabilities setting — the setting does not appear to propagate to the Routine's session proxy policy.

Impact

This blocks any Routine use case that needs to browse/verify public web content (news monitoring, lead generation, research agents, etc.) — the routine can still use WebSearch (server-side, works fine) but cannot fetch or verify a specific source URL, which forces routines to fall back to unverified search snippets or fail outright.