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

[dust2dustin]

Description

When a scheduled task triggers a permission prompt during execution, only the "Allow once" option is presented. The "Always allow" option that appears in interactive CLI sessions is missing.

This makes it difficult to achieve fully automated scheduled tasks — each run may re-prompt for the same permission, and since the user isn't watching a scheduled task, the prompt blocks execution indefinitely.

Expected behavior

Permission prompts in scheduled task context should offer "Always allow" (persist to settings) in addition to "Allow once", matching the behavior of interactive sessions.

Steps to reproduce

1. Create a scheduled task that uses curl or playwright-cli commands
2. Run the task via Claude Code Desktop scheduler
3. Observe that permission prompts only show "Allow once" — no "Always allow" option

Environment

• Claude Code Desktop (macOS)
• Scheduled tasks via ~/.claude/scheduled-tasks/
• Commands that should match existing auto-allow patterns (e.g., curl, playwright-cli) still trigger prompts in scheduled context

Workaround

Pre-configuring exact command patterns in ~/.claude/settings.json under allowedTools works for some commands, but the interactive "Always allow" flow would be much more ergonomic for discovering which permissions a task needs.

[github-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

[Stvad]

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)

[yurukusa]

/tmp/gh-comment-body.txt

[jacksonhux]

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.

[Milesenberg]

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.