Scheduled routines: no way to grant standing tool permissions — unattended runs stall on permission prompts

Summary

Scheduled cloud routines (claude.ai/code/routines) have no way to grant standing tool permissions. Every run — scheduled or manual — re-prompts for permission on each tool family it uses (shell/file tools, connector MCP tools like Gmail/Calendar/Dropbox), and the prompt dialog offers no "always allow for this routine" option. When a run fires unattended (the entire point of a scheduled routine), it stalls on the first prompt until the user next opens the app and clicks through.

Evidence that unattended runs stall

Observed on several daily/weekly routines (migrated from Cowork desktop scheduled tasks; created_via: meta_mcp, model claude-sonnet-5):

• A weekly routine fired at 06:07 UTC (11:07 PM local); its output file was only written at ~10:22 AM local the next morning — the moment the user opened the Claude app and could approve the queued permission prompts.
• A daily routine fired at 6:03 AM local; its file changes landed at ~9:53 AM local, again coinciding with the user opening the app.
• Manually triggering a routine (POST /v1/code/triggers/{id}/run) while watching produces a continuous barrage of per-tool permission prompts.

So scheduled routines currently only "run" when their owner happens to open the app afterwards — which defeats unattended scheduling (e.g., a morning brief that should be ready before the user sits down).

What we tried

Updated the routine's job_config.ccr.session_context.allowed_tools via the triggers API to explicitly pre-approve everything the routine uses, including:

• built-in tools by name (Bash, Read, Write, Edit, WebFetch, WebSearch, Skill, SendUserFile, TodoWrite, …)
• preset:default
• MCP connector entries in both server-level and wildcard forms (mcp__Gmail, mcp__Gmail__*, mcp__Dropbox, mcp__Dropbox__*, mcp__Google_Calendar, mcp__Google_Calendar__*, …)

The update was accepted and stored (verified via GET), but a subsequent manual run still produced the same permission prompts — allowed_tools does not appear to suppress the permission dialogs for these routine sessions.

Expected

One (or more) of:

1. A per-routine "always allow these tools for this routine's runs" setting (UI checkbox on the prompt dialog, or honored allowed_tools in the routine config), or
2. Scheduled/unattended runs auto-approving tools that are declared in the routine's config, with the config edit itself being the consent step.

Impact

Scheduled routines are not useless in the current form, but their convenience and value are much reduced: every "unattended" run is effectively deferred until the user is present, and interactive runs are a prompt-clicking exercise. The core promise of the feature — work that happens while you're away — doesn't hold.

---

Filed from a Claude Code session on the user's behalf, at their request.