[FEATURE]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Adding a concrete case for this — I have a Cowork scheduled routine polling three ADS-B data APIs (adsb.lol, adsb.fi, airplanes.live) hourly for an operational aircraft-tracking tool. Starting the evening of 2026-08-26, all three began returning a PROVENANCE_REQUIRED permission response specifically to the scheduled/unattended run — the identical fetch to the same domains works fine from an interactive session. Before that point the scheduled poller had been running successfully.

There's no way for me to allowlist these domains for the scheduled routine's environment: the trigger/routine config has no domain field, and the org-level Capabilities network setting (where it exists) doesn't govern this environment. The result is a fully broken automation with no self-serve recovery path — I'm currently having to manually re-run the fetch from an interactive session every few days just to keep the data current.

Please prioritize scheduled-routine domain allowlisting (as proposed here in #50146). This is a real production blocker, not a hypothetical.

Proposed Solution

Proposed Solution

Extend the existing sandbox network-allowlist mechanism (sandbox.network.allowedDomains, already used for local/interactive sandboxing) to cover scheduled routines. Two placement options, not mutually exclusive:

1. Environment-level default — an allowedDomains list set once at https://claude.ai/code/scheduled that applies to every routine/trigger running in that environment. Lowest-effort fix, covers the common case where a user has one or two external APIs their automations need repeatedly.

1. Per-trigger override — a domains field on the individual trigger/routine definition itself (alongside cron_expression, prompt, model, etc. in create_trigger/update_trigger), for cases where different scheduled tasks need different domains and a single environment-wide list is too broad.

Either would unblock this. A per-trigger field is the more precise long-term design, but an environment-level list would be a reasonable v1.

Separately, regardless of which mechanism ships: today a domain block on a scheduled run fails silently as a generic PROVENANCE_REQUIRED response from the target API, not as a labeled platform-level error. A user has no way to tell "the external API rejected us" from "Anthropic's sandbox blocked this domain for unattended runs" without manually testing the same fetch from an interactive session and comparing behavior — which is how this got diagnosed here. Surfacing a clear, distinct error (e.g. "blocked-by-allowlist: scheduled runs cannot reach <domain>; add it in <settings location>") would make this self-diagnosable even before the allowlisting feature itself ships, and would help with the related bugs already filed about the allowlist not being respected consistently (#23818, #30112, #19087).

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

Configuration and settings

Use Case Example

I run automated scheduled tasks (Cowork routines) that need to reach specific external APIs on a recurring, unattended basis. There's no way to grant a scheduled routine's environment access to a domain that isn't already on some baked-in default allowlist — the trigger/routine definition has no domain configuration field, and the org-level Capabilities network setting (where it exists) doesn't extend to this environment.

This became a real production problem on 2026-08-26: an hourly routine I depend on started getting a PROVENANCE_REQUIRED permission response from three external APIs it had been reaching successfully, specifically when run on schedule — the identical request from an interactive session works with no issue. Because there's no visibility into why a domain is blocked for scheduled runs versus interactive ones, and no setting to fix it, the automation is now fully broken with no way for me to self-recover it. I have to manually re-run the underlying fetch from an interactive session every few days just to keep the data from going stale, which defeats the purpose of scheduling it.

Additional Context

Related open issues on the same underlying gap:

• #23818 — Cowork VM network egress allowlist ignores Admin Capabilities settings
• #30112 — Cowork network egress allowlist not working, custom domains blocked with 403 blocked-by-allowlist
• #19087 — Additional allowed domains setting not applied to Claude Code container network egress

Together these suggest the allowlist story is inconsistent across every environment it touches (local sandbox, Cowork VM, and now scheduled routines) — not just a single missing field. Worth considering a unified allowedDomains mechanism that behaves the same way everywhere, rather than patching the routine case in isolation.

Technical note: the product already has a working pattern for this exact concept in sandbox.network.allowedDomains for local/interactive sandboxing. Extending that same mechanism (or exposing an equivalent) to scheduled routines seems like the smallest-diff fix rather than inventing new config surface.