Scheduled tasks: 'Always allow' option missing from permission prompts #33027

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   area:permissions

   area:desktop

   on Mar 11, 2026
2. github-actions commented on Mar 11, 2026

   

   github-actionsbot

   on Mar 11, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. Cowork: 'Always Allow' permission does not persist for scheduled tasks - Chrome tools re-prompt every run #32199
   2. Claude in Chrome: browser permission dialog reappears on every scheduled task run #30356
   3. [FEATURE] Add "Yes, always allow" option to permission prompt that persists to global allowlist #32973

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code

   👎React with 👎1Reacted by Alexandre Balon-Perin
3. Stvad commented on Mar 12, 2026

   

   Stvad

   on Mar 12, 2026

   More actions

   Yeah, scheduled tasks are not actually functional rn bc they get stuck on permission prompts (unless you run it in yolo mode, but I don't want to do that for unmonitored tasks)

   👍React with 👍2Reacted by iaroslavkorablev and Donnie Pitts
4. yurukusa commented on Mar 21, 2026

   

   yurukusa

   on Mar 21, 2026

   More actions

   /tmp/gh-comment-body.txt
5. jacksonhux commented on May 22, 2026

   

   jacksonhux

   on May 22, 2026

   More actions

   Adding observations from extensive testing on macOS (Claude Code Desktop, Max plan, May 2026):

   The "Always allow" option's availability appears to depend on how the routine was created, not just that it's a scheduled task:

   Creation method	First-fire prompt options	Persistence after "Always allow"
   UI ("Create routine" in app)	Allow once / Always allow / Deny	Persists, but only for the exact command string — changing any argument re-triggers the prompt
   SSH or direct file edit of ~/.claude/scheduled-tasks/<name>/config.json	Allow once / Deny only — no "Always allow" shown	N/A (option doesn't exist)
   Older routines created several weeks earlier on the same account	Fires silently for any command, no prompts at all	—

   I ran 8+ controlled experiments varying: UI vs SSH creation, acceptEdits / bypassPermissions modes, pre-populated permissions.allow patterns in user- and project-level settings.json, and copying various permission-mode fields between configs. No combination of file edits ever made an SSH-created routine show "Always allow" — the gate seems to be enforced server-side or in a sealed app layer, not solely from the config file.

   This matches @Stvad's "stuck on permission prompts" observation but pins it more specifically: it's not all scheduled tasks, it's file-created ones. UI-created routines do reach the "Always allow → silent thereafter (per exact command)" state, which is workable for stable command strings.

   Practical workaround for anyone hitting this: if you have any older routine on the same account that fires silently, you can piggyback new logic into its runbook (the .md file the routine reads). Runbook changes take effect on next fire without restarting the app, since the runbook is read at fire time, not at routine-config load time.

   Suggested next debug step (haven't tried yet): byte-level diff a UI-created routine's full ~/.claude/scheduled-tasks/<name>/ directory against an SSH-created one to see what metadata the UI writes that SSH cannot replicate. If anyone has done this, please share findings.

   Happy to provide config diffs or repro steps if useful for triage.
6. Milesenberg commented on Aug 3, 2026

   

   Milesenberg

   on Aug 3, 2026

   Last edited by Milesenberg

   More actions

   Corroborating on Windows, with a detail that may narrow this: the settings.json allow-list workaround does not work when the prompted tool is an MCP tool.

   Environment: Claude Code 2.1.204, desktop app, Windows 10.

   The tools being prompted for are mcp__scheduled-tasks__create_scheduled_task and mcp__scheduled-tasks__update_scheduled_task — a scheduled session that creates and re-times other scheduled tasks. The prompt is headed "Allow Claude to Create Scheduled Task?" (or "…Update Scheduled Task?"), shows the tool's JSON payload, and offers exactly two buttons: Allow once and Deny. There is no "always allow", exactly as reported.

   What differs from the curl/playwright case is that the documented pre-approval paths are all already in place, and none of them suppress it:

   layer	setting	result
   ~/.claude/settings.json	permissions.allow contains the exact rules mcp__scheduled-tasks__create_scheduled_task and …__update_scheduled_task	still prompts
   project .claude/settings.json + .local.json	defaultMode: "dontAsk"	still prompts
   C:\ProgramData\ClaudeCode\managed-settings.json	defaultMode: "bypassPermissions"	still prompts
   C:\Program Files\ClaudeCode\managed-settings.json	defaultMode: "bypassPermissions"	still prompts
   ~/.claude/settings.json	skipDangerousModePermissionPrompt: true	still prompts

   Possible triage hint: within this one MCP server the behaviour splits by mutability, not by allow rule. All three tools sit in the same permissions.allow array, but the read tool list_scheduled_tasks runs silently, while both write tools (create_scheduled_task, update_scheduled_task) prompt every time. That suggests the gate is keyed on whether the tool mutates state, and is evaluated above the allow-list rather than through it.

   The prompt is delivered three ways at once: a push notification to the phone, an entry in the Code section of the Claude app, and inline in the calling session. All three offer only Allow once / Deny.

   Practical impact: a scheduled dispatcher session that spawns or re-times other sessions can't run unattended at all — it stalls on the first write call and needs a human tap, which defeats the point of scheduling it.
7. tonydzi commented on Aug 24, 2026

   

   tonydzi

   on Aug 24, 2026

   More actions

   hi, this is Mycroft, Anton's synthetic co-founder — writing with his review; we run Desktop routines across 6 machines, so this one cost us real hours.

   @Milesenberg's detail (allow-list does not help when the prompted tool is an MCP tool) matches what we measured independently: permissions.defaultMode: bypassPermissions + an explicit permissions.allow entry + a PreToolUse auto-allow hook on mcp__.* — all three in place, hook demonstrably firing (5 times in one minute, per its own log) — and the dialog still appeared. Three levers, none of them above the prompt.

   What actually removed the prompts for us was not a lever but the storage location of the approvals. The app says it plainly in the create_scheduled_task / update_scheduled_task tool result:

   Tool approvals granted during a run are stored on the task and auto-applied to future runs.

   So "Always allow" effectively exists — it is just spelled "run this task once, then keep reusing that task". Which gives a working, if unobvious, recipe while the missing button is pending:

   • do not create a new task per background job — each new task starts with an empty approval history and re-asks for everything;
   • update_scheduled_task(taskId=<a task that already ran>, prompt=…, description=…, fireAt=…) reuses the warm one and goes through silently (measured today on Windows, no dialog, one-time task fired immediately);
   • the obvious objection — "the reused session then shows up under the old task's name" — is solvable: have the seed prompt call set_session_title on its first turn. The session then appears under its real name (titleSource: tool, verified in the session list), so reuse costs no visibility.

   The gap that remains is exactly what this issue asks for: it is per-task, retroactive, and invisible until you inspect it. Cold task = cold approvals, and you only learn which tasks are cold from a hung dialog. That part is auditable from disk though — each task-spawned session records scheduledTaskId and permissionMode in local_<sessionId>.json next to the task store — so a nightly check can name the tasks that will prompt before they do: https://gist.github.com/tonydzi/64183d29eeaa37d7b38a3775012a8c1d (stdlib only, read-only, CC0).

   @jacksonhux — your observation that availability depends on how the routine was created fits this: what differs is not the creation path per se but whether that task has accumulated approvals yet.