Cloud routines (CCR) egress proxy blocks reaching third-party APIs — no user-configurable allowlist

Description

A scheduled Cloud routine (created via the Claude Code /schedule flow, backed by the RemoteTrigger API) needs to call a third-party SaaS API from Bash inside its CCR sandbox (environment kind anthropic_cloud, id env_01VtnYFmhfbnP7L1TDMDVbDy). Every outbound HTTPS call to that host fails at the network layer:

error connecting to API: error sending request for url (https://api.hotdata.dev/v1/databases/...)
[agent-proxy] While this command ran, 12 connections through the agent proxy failed:
 - api.hotdata.dev:443 — connect_rejected (the egress proxy denied the CONNECT (organization policy) or could not reach the destination)

Querying the sandbox's own proxy status endpoint (curl http://127.0.0.1:<port>/__agentproxy/status) confirms the egress proxy's allowlist only covers:

• Anthropic's own APIs (api.anthropic.com and friends, mcp-proxy.anthropic.com)
• A handful of package registries (registry.npmjs.org, pypi.org, files.pythonhosted.org, index.crates.io, jsr.io, etc.)

There is no setting — in the routine config, environment config, or account settings — to add an arbitrary third-party API host to that allowlist. MCP-connector traffic (e.g. Gmail, HubSpot) works fine from the same routine because it's routed through the separate MCP proxy; only direct outbound HTTPS from Bash/CLI tools hits this restrictive allowlist.

Impact

Any Cloud routine that needs to call a legitimate third-party API/CLI directly (not via an existing MCP connector) is permanently blocked, with no workaround available to the user — this isn't a credentials or configuration issue on the routine's side, it's a hard network-policy wall with no escape hatch.

Repro steps

1. Create a routine via /schedule (or the RemoteTrigger API) targeting the "Default" anthropic_cloud environment.
2. Give it a prompt that runs a Bash command calling any non-allowlisted third-party API host over HTTPS.
3. Every connection attempt is rejected by the agent proxy before reaching the destination, with connect_rejected (... organization policy ...).

Evidence

• environment_id: env_01VtnYFmhfbnP7L1TDMDVbDy
• 4 identical failing runs reproduced on 2026-09-07: session ids cse_01NnDSTPcRXvHM3ATEpkvGHv, cse_0164WMKoTxVhUsEwZjqxmPnc, cse_01BufC55gg5TPjUKSi8ikZvY, cse_015Wnn8caCPZAe3fFzrLbcov
• Target host: api.hotdata.dev:443
• Each run independently confirmed the block via its own /__agentproxy/status check rather than guessing

Suggested fix

Expose a user-configurable egress allowlist per environment (or per routine) so a routine's own legitimate third-party API calls aren't unconditionally blocked — e.g. a list of allowed hostnames settable from the routine/environment configuration UI or API.