Scheduled tasks: 'Always allow' option missing from permission prompts
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
- Create a scheduled task that uses
curlorplaywright-clicommands - Run the task via Claude Code Desktop scheduler
- 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.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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)
/tmp/gh-comment-body.txt
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/bypassPermissionsmodes, pre-populatedpermissions.allowpatterns in user- and project-levelsettings.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
.mdfile 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.