[BUG] Cowork scheduled tasks: WebFetch permission gate (PROVENANCE_REQUIRED) blocks unattended runs on parallel calls

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?

Scheduled tasks (Cowork Routines) running unattended sometimes have WebFetch calls fail with a PROVENANCE_REQUIRED error when multiple fetches are made in parallel (e.g., subagents each fetching a different external URL at the same time). Since the task runs with no human present, nothing can resolve the gate interactively, and in some cases the agent misdiagnoses this as a full network/policy block rather than a transient, retryable condition — causing it to mark perfectly reachable sources as "unreachable" and skip them entirely.

What Should Happen?

WebFetch should either handle concurrent calls without triggering this gate, or scheduled/unattended sessions should be able to pre-approve WebFetch access so it doesn't intermittently fail with no way to resolve it. This overlaps with the broader "permissions don't persist across scheduled runs" bug class (#47180, #77817, #40470, #33027, #59302) — likely the same root cause of permission state not carrying into unattended scheduled sessions.

Error Messages/Logs

WebFetch returned PROVENANCE_REQUIRED errors on all URLs attempted
(permission gate requiring interactive approval that never resolved)

Some agent instances additionally misinterpreted this as a hard network block, incorrectly reporting 403-style proxy denials on retry rather than recognizing it as the same recoverable gate.

Steps to Reproduce

1. Create a scheduled task (Routine) that fetches multiple external URLs, ideally by spawning several subagents that each call WebFetch concurrently.
2. Let the task run unattended on its schedule (no one watching/available to approve prompts).
3. Observe that some WebFetch calls fail with PROVENANCE_REQUIRED while others succeed.
4. Retry the same failed URLs one at a time, sequentially (not concurrently) — this succeeds every time, confirming the sites/URLs themselves are fine and the issue is specific to concurrent WebFetch calls in an unattended session.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Cowork

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround: serializing WebFetch calls (one at a time) instead of firing them in parallel avoids the gate reliably, but this isn't practical for tasks that need to check many sources quickly under a scheduled run's time/token budget. Related issues: #47180, #77817, #40470, #33027, #59302.