Cloud routines (RemoteTrigger/CCR): WebFetch and direct curl blocked for nearly all external domains by egress proxy

Description

Scheduled cloud routines (created via the RemoteTrigger API / "Routines" feature) run in a sandboxed CCR environment behind an egress proxy. In that environment, the WebFetch tool — and even direct curl calls from Bash — are blocked with EGRESS_BLOCKED / a 403 on CONNECT for nearly every external domain tried, while WebSearch continues to work normally.

Domains observed blocked (via WebFetch EGRESS_BLOCKED and/or direct curl 403 on CONNECT)

• youtube.com / m.youtube.com (confirmed blocked even via raw curl, not just WebFetch)
• www.sofascore.com
• www.atptour.com
• www.wtatennis.com
• www.itftennis.com
• tennismagazine.jp
• news.tennis365.net
• news.yahoo.co.jp
• en.wikipedia.org / ja.wikipedia.org
• x.com, google.com, and several third-party aggregators (yutura.net, socialblade.com, piped.video, r.jina.ai, playboard.co)

WebSearch was unaffected and returned normal results throughout.

Steps to reproduce

1. Create a scheduled routine (RemoteTrigger create) that uses WebFetch to read a specific page (e.g. a YouTube channel's /videos page, or any tennis news/scores site).
2. Let it fire, or trigger it manually.
3. Inspect the run log via get_run_log — WebFetch calls to the above domains return {"error_type":"EGRESS_BLOCKED","domain":"...","message":"Access to ... is blocked by the network egress proxy."}.
4. As a further check, a Bash step running curl directly to https://www.youtube.com also fails with CONNECT tunnel failed, response 403 ... (organization policy).

Expected behavior

Either WebFetch/curl should be able to reach ordinary public websites from within a routine's sandbox (same as it can from an interactive Claude Code session), or, if this is an intentional network allowlist, the allowlist should be documented so routine authors can design around it (and ideally routines should get a clear, actionable error rather than silently losing this capability).

Actual behavior

Nearly all outbound HTTP(S) traffic from the routine sandbox is silently blocked except to a short allowlist (per $HTTPS_PROXY/__agentproxy/status, only things like api.anthropic.com, registry.npmjs.org, pypi.org, etc. are in noProxy). This makes WebFetch-dependent routines effectively non-functional, since WebSearch alone often cannot substitute for reading a specific live page (e.g. determining a YouTube channel's single most recent upload with its exact video ID and upload date — WebSearch's index skews toward older/popular videos and rarely surfaces exact recency).

Impact

A routine on our project that reads YouTube channel pages to keep a "latest videos" list up to date has been completely non-functional for 2+ consecutive daily runs because of this — every attempt (including 4 parallel sub-agents trying different domains/mirrors) hit EGRESS_BLOCKED. The routine correctly declines to fabricate data and just reports the failure, so there's no data-quality issue, but the underlying feature (routines that need to fetch specific external pages) is broken.

Other routines on the same project that also rely on WebFetch (e.g. checking match results on sofascore.com, or reading specific news articles) had to fall back to WebSearch-only strategies, which is a degraded/best-effort substitute, not a real fix.

Environment

Observed via RemoteTrigger scheduled routines (job_config.ccr) using environment_id: env_01MYFK8aY9VzJwYsvGX2R6ch (the only "Default"/"anthropic_cloud" environment offered), model claude-sonnet-5, allowed_tools including WebFetch/WebSearch/Bash. Confirmed across multiple independent routine runs and sub-agent sessions over several days, so this is consistent/persistent rather than a one-off blip.

Start with the RemoteTrigger create flow and inspect routine runs through get_run_log, focusing on WebFetch and Bash curl failures. Check the documented $HTTPS_PROXY/__agentproxy/status output and the job_config.ccr environment details; done means identifying the routine sandbox egress behavior and defining whether access, allowlist documentation, or actionable errors are required.