[FEATURE] Routines need a permission default that applies to spawned sessions without attending a run

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

Every documented way to give a routine the permissions it needs requires a human present at a run — which is the one thing a routine exists to avoid.

I run local Desktop routines that fire unattended, including overnight. When a run spawns without the permission mode I configured, it blocks on its first permission prompt, completes zero turns, writes nothing to its run log, and sits silently in the sidebar. Nobody sees it. The next firing spawns another one. By morning there are N frozen sessions, each waiting on its own prompt, each needing to be opened and unfrozen individually — and another one spawns while you're working through them. For an hourly routine this compounds overnight.

Here is why each existing mechanism doesn't close the gap:

1. The per-task permission mode is the right shape but isn't reliably honored at spawn. Measured on my macOS machine: 23 of 77 routine-spawned sessions (30%) spawned in default despite the task being set to Bypass permissions in the Routines UI the entire time. One routine spawned Manual on 9 of its 19 runs. On the Windows machine in #77817 it's 133 of 133. Details and method in that thread.

2. The documented mitigation cannot work for unattended runs, by construction. From the docs:

To avoid stalls, click Run now after creating a task, watch for permission prompts, and select "always allow" for each one. Future runs of that task auto-approve the same tools without prompting.

This requires attending a run. If the routine fires at 3am, there is no one to click. It also assumes every tool the routine will ever need can be enumerated from one observed run — any new command or MCP tool re-stalls it. And it reportedly doesn't hold even when you do attend: #33027 (the "Always allow" option is missing from scheduled-task prompts entirely, open since March) and #76141 ("Always allow" doesn't persist across scheduled runs).

3. Allow rules in settings.json don't fully suppress it. They do apply to scheduled sessions, but per #77817 a 57-rule allowlist covering every command and MCP tool those routines use still prompted on every launch — whatever run-level gate Manual mode applies isn't reachable by permission rules.

4. There is no programmatic path. create_scheduled_task / update_scheduled_task expose no permission-mode parameter, and the mode isn't in the task's SKILL.md. So it can't be set at creation, audited, scripted, or fixed in bulk — only clicked, per task, in the Edit form. The docs' "change them through the Edit form or ask Claude" line omits permission mode from its list, and "ask Claude" isn't actually available for it.

Net effect: a user who has deliberately decided their unattended automation should run in a given permission mode has no way to express that once and have it hold.

Proposed Solution

A permission default for routines that is inherited by every session the routine spawns. Concretely, three properties:

1. Applied deterministically at spawn. If a routine is set to Bypass permissions, every session it spawns starts in Bypass — not 70% of them. This is the core ask; without it the other two don't matter.

2. Settable without the UI. A permissionMode parameter on create_scheduled_task / update_scheduled_task, and/or a field in the task's SKILL.md frontmatter. This makes it settable at creation, auditable, scriptable, and fixable in bulk — today a user with N routines fixes an N-times-repeated problem by hand, and again for every new routine.

3. A global default for new routines. Something like scheduledTasks.defaultPermissionMode in settings.json, or restored honoring of permissions.defaultMode for tasks with no explicit per-task value (per #77817). Otherwise every future routine silently starts in Manual and needs the same manual fix.

I am not asking for bypass-by-default. Manual can stay the default for new tasks, and the security reasoning for tightening unattended permissions makes sense. The ask is that a user who has deliberately chosen a permission level for unattended work can express that choice once — programmatically — and have it actually hold at spawn.

A useful smaller step, if the above is large: allow a routine's tool approvals to be pre-authorized without attending a run — e.g. an "always allow" list on the task's detail page that can be populated up front rather than only by answering live prompts. The detail page already has an Always allowed panel for reviewing and revoking approvals; being able to add to it directly would remove the attendance requirement even if per-task mode resolution stays as-is.

Environment: Claude Code 2.1.219 (Claude Desktop), macOS 26.5.2. Two local routines, both created via create_scheduled_task.

Related issues — this overlaps the Requests list in #77817 and may be worth merging there; filing separately because the attendance-impossibility of the documented mitigation isn't covered by any of them:

• #77817 — per-task mode not honored / not programmatic / no bulk control (bug)
• #33027 — "Always allow" option missing from scheduled-task prompts (open since March)
• #76141 — "Always allow" doesn't persist across scheduled runs (closed as completed)
• #76469 — permission mode edit doesn't save for NL-created routines

Alternative Solutions

Things I've actually tried, and why each falls short:

1. Setting the per-task permission mode in the Edit form. This is the intended path and I have it set to Bypass permissions on both routines. It's honored on ~70% of spawns; the other 30% spawn Manual and die at zero turns. Setting it is necessary but not sufficient.

1. Building a broad allow-list in ~/.claude/settings.json. Allow rules do reach scheduled sessions, but per #77817 they don't suppress whatever run-level gate Manual mode applies — a 57-rule allowlist there still prompted every launch.

1. Run now + "always allow" on each prompt, as the docs recommend. Requires attending a run, so it can't cover overnight firings, and it only pre-authorizes tools you happened to observe.

1. Setting the mode via update_scheduled_task. Not possible — no permission-mode parameter exists. Editing the task's SKILL.md on disk doesn't work either; the mode isn't in that file.

1. Moving the work to a /loop in an open session. This is my current workaround and it does solve the permission problem — a /loop inherits the mode of the session I opened, so it never stalls. The cost is that it only runs while that session is open: close the app or let the machine sleep and the chain dies silently, with nothing external to resume it. I lost a week of unnoticed missed runs to exactly that. So I'm trading a silent permission failure for a silent liveness failure.

1. A SessionStart watchdog hook that scans session metadata and reports any routine run with 0 completed turns. This is what I run now. It converts a silent failure into a visible one — it does not prevent it, and I still have to go unfreeze each session by hand. Needing to write this at all is the clearest signal the gap is real.

The workaround I want — "just set the permission level on the routine once" — is the thing that doesn't reliably exist.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Scenario: an overnight triage routine that should need no supervision.

1. I have a local Desktop routine that runs a bug-triage workflow against an internal Jira board and a dev server. It reads tickets, reproduces issues, and prepares fixes. It needs shell commands and MCP tools throughout, so it must run in Bypass permissions to work unattended.
2. I set the routine's permission mode to Bypass permissions in the Edit form. This is the documented, intended way to do it.
3. The routine fires on a schedule, including while I'm asleep.
4. ~30% of the time the session spawns in Manual instead. It hits its first tool call, raises a permission prompt nobody is awake to answer, completes zero turns, and writes nothing to its run log. It looks identical to a run that simply hasn't started yet.
5. The next firing spawns a fresh session. Same thing. Nothing links them; nothing surfaces the problem.
6. In the morning I have a stack of frozen sessions in the sidebar. Each one has to be opened and answered individually — and if the routine is hourly, another spawns while I'm working through them. The work they were supposed to do overnight simply didn't happen.
7. The documented fix — click Run now, watch for prompts, choose "always allow" — assumes I was there. At 3am I wasn't. That's the entire reason the routine exists.

With this feature: I set the permission mode once, at creation, via create_scheduled_task (or a global default in settings). Every session that routine spawns starts in that mode. Overnight runs complete. Nothing to unfreeze in the morning, and nothing to babysit.

What I actually do today: I moved the work to a /loop inside a session I keep open, because a /loop inherits my session's permission mode and therefore never stalls. That trades the permission failure for a liveness failure — the loop dies silently whenever the app closes or the machine sleeps, which already cost me a week of unnoticed missed runs. I also wrote a SessionStart watchdog hook that flags routine sessions with 0 completed turns, purely so the silent failures become visible. Both of these exist only to work around the missing setting.

Additional Context

_No response_