[BUG] Cowork scheduled tasks ignore "Always allow" folder/tool permissions — prompts reappear every run (macOS)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40470
2. https://github.com/anthropics/claude-code/issues/33027
3. https://github.com/anthropics/claude-code/issues/24433

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

Adding a specific reproduction detail: When a scheduled task with permissionMode: "bypassPermissions" prompts for an MCP tool permission and the user clicks "Allow," the desktop app adds an approvedPermissions array to that task's entry in scheduled-tasks.json. For example:

{
  "id": "slack-nic-bot",
  "permissionMode": "bypassPermissions",
  "approvedPermissions": [
    { "toolName": "mcp__4bfcea91-87e6-4e2c-bf15-15cefb3f481f__slack_send_message" },
    { "toolName": "mcp__4bfcea91-87e6-4e2c-bf15-15cefb3f481f__slack_update_canvas" }
  ]
}

This causes two compounding problems:

1. The approvedPermissions array becomes an exclusive whitelist. Once it exists, the task can only use those specific tools — all other tools (including ones in the global settings.local.json allow list) are blocked and prompt again. So approving one tool breaks all the others.

1. The MCP tool names use session-specific UUIDs (e.g., mcp__4bfcea91-...) instead of the stable claude_ai names (e.g., mcp__claude_ai_Slack__slack_send_message). These IDs go stale across sessions, so even the "approved" tools eventually stop matching.

Workaround: Manually editing scheduled-tasks.json to remove the approvedPermissions array entirely restores the task to using the global allow list. But the array gets re-added every time the user approves a prompt.

Expected behavior: Tasks with permissionMode: "bypassPermissions" should not prompt for MCP tools at all, and should not create an approvedPermissions array.

Environment: Claude Desktop on macOS, bypassPermissionsModeEnabled: true and dispatchCodeTasksPermissionMode: "bypassPermissions" set in claude_desktop_config.json.

+1 — this is a major blocker for my workflow.

I have a custom Cowork skill that automates image generation on Freepik Pikaso for YouTube video production. Because of context window limits, the skill is designed to generate 10 images per session, then automatically create a scheduled task (via mcp__scheduled-tasks__create_scheduled_task) to continue from where it left off 15 seconds later — using a checkpoint JSON file to track progress.

The idea is fully autonomous batch processing: generate 10 images → save checkpoint → schedule next session → new session reads checkpoint → generates next 10 → repeat until all 100-200 scenes are done.

The problem: every time the skill calls create_scheduled_task, Cowork shows a confirmation dialog ("Schedule" / "Cancel") that requires manual approval. This happens on every single batch, even though:

• The skill explicitly instructs Claude to schedule without asking for confirmation
• I've tried adding ~/.claude/settings.json with allow rules
• I've clicked "Always allow" on previous runs

Nothing persists. The permission prompt comes back every time.

This defeats the entire purpose of the checkpoint + auto-continue pattern. Instead of walking away and coming back to 200 generated images, I have to sit and click "Schedule" every ~15 minutes.

If anyone has found a workaround for this — any hack, config trick, or alternative approach to chain Cowork sessions without the permission prompt — I'd really appreciate hearing about it. This is seriously slowing down my production pipeline and I'd love to find even a temporary solution while we wait for an official fix.

What I'd like to see from Anthropic:

• A per-task or per-skill "always approve" toggle for create_scheduled_task
• Or at minimum, respect the ~/.claude/settings.json allow rules for scheduled task creation
• Ideally, skills should be able to declare trusted tool calls that bypass confirmation

Environment: macOS, Claude Desktop (latest), Cowork with custom skills + Claude in Chrome extension.

+1 Same issue, renders the feature pointless as it stands sorry. Tasks never run without user input and I can't see a way of giving them permission to read/write to project files so they can run.

Similar problem.

Same problem, make cowork unusable right now.

We are having the same issue with our Apple MacBook Pro Users

+1. Completely discards the functionality.

+1 with Windows repro and new data not yet in this thread.

Environment: Claude Desktop 2.1.111 on Windows 11 with claude-code-desktop scheduler (ccdScheduledTasksEnabled: true). bypassPermissionsModeEnabled: true and defaultMode: "bypassPermissions" both set. Same symptoms as the macOS reports.

Confirming @nic-astro's diagnosis with more detail: approvedPermissions really does behave as an exclusive whitelist. From %APPDATA%\Claude\logs\main.log when a task has the array set but calls a tool not in it:

[CCDScheduledTasks] Not auto-approving "Bash" in scheduled task "<task-a>":
rule(s) not in stored approvals: Bash, Bash, Bash (stored count=0)

[CCDScheduledTasks] Not auto-approving "Edit" in scheduled task "<task-b>":
no suggestions on request

[CCDScheduledTasks] Not auto-approving "Bash" in scheduled task "<task-b>":
suggestions contained no addRules/replaceRules

Note the second and third forms — tasks with NO approvedPermissions array still fail to auto-approve because the SDK does not emit addRules/replaceRules suggestions for Edit, Write, or Bash in scheduled-task sessions. Global settings.json allow rules appear to be ignored by this codepath entirely.

Additional data point — undocumented global concurrency cap of 3: When three tasks block waiting on permission prompts overnight, every other task is SKIPPED (not queued):

[CCDScheduledTasks] Skipping dispatch for <task-c>: global_limit (active=3, limit=3)
[CCDScheduledTasks] Skipping dispatch for <task-d>: global_limit (active=3, limit=3)
[CCDScheduledTasks] Skipping dispatch for <task-e>: global_limit (active=3, limit=3)

This repeats every minute from roughly midnight UTC until a human is present to dismiss the stuck prompts (~07:00 UTC in my case). Effect: one unresolved prompt silently poisons every subsequent scheduled run for hours. The cap is not documented in the scheduled-tasks MCP or in any settings field I can find. Even if the permission issue were fixed, this cap would still warrant either documentation or an auto-timeout on stuck prompts, so a prompt-stalled task can't wedge the whole scheduler.

UI observation on top of @nic-astro's report: when running a task manually via "Run Now," Bash prompts offer an "Always allow" button and it persists. Edit and Write prompts only offer "Once" — no "Always" button appears at all. Confirmed today across three different tasks.

Issue is not platform-specific — suggest removing the platform:macos label.

+1 with concrete Windows + headless reproduction evidence.

Setup: Claude Code v2.1.114, Windows 11, scheduled tasks (not Cowork). 25 active scheduled tasks all using permissionMode: "bypassPermissions".

Exclusive-whitelist behavior reproduced. After running each task once with bypassPermissions, three of them ended up with approvedPermissions arrays:

{ "id": "communications-manager", "permissionMode": "bypassPermissions", "approvedPermissions": [{"toolName": "Edit"}] },
{ "id": "executive-sitrep",       "permissionMode": "bypassPermissions", "approvedPermissions": [{"toolName": "mcp__google-workspace__get_events"}] },
{ "id": "swat-team-manager",      "permissionMode": "bypassPermissions", "approvedPermissions": [{"toolName": "Edit"}] }

After the array appeared, those tasks lost access to everything else — executive-sitrep could only read calendar events but not write its own report; the others could only Edit but couldn't Read/Bash/Write. Confirms @nic-astro's "exclusive whitelist" diagnosis exactly.

Workaround: manually delete the approvedPermissions arrays from scheduled-tasks.json. Tasks immediately recover and use the global allow list again. (As @nic-astro noted, the array reappears on the next prompt though.)

Additional evidence — PermissionRequest hook is firing, but the protected-paths gate short-circuits before it. Installed an auto-approve PermissionRequest hook that returns {"decision":"allow"} for every event. 593 audit log entries confirm it fires on every reachable prompt. But scheduled-task writes to ~/.claude/ (e.g., Edit C:\Users\AdamK\forgeapps\.claude\hooks\permission-audit.sh) STILL prompt — those events never appear in the audit log because the hook never gets dispatched. This matches the headless-vs-interactive split documented in #35646: in -p/scheduled-task mode the protected-paths check short-circuits before PermissionRequest.

Concrete asks:

1. With permissionMode: "bypassPermissions", don't add approvedPermissions arrays at all — or ignore them entirely. The mode says bypass; the array contradicts it.
2. Make the protected-paths gate respect bypassPermissions in headless mode the same way it does interactively (see #35646, #36168, #37253, #40463).
3. Use stable MCP tool names in approvedPermissions (not session-UUID-prefixed ones) — they go stale every session per @nic-astro.

Related open issues that all stem from the same root cause: #36168, #37253, #40463, #43736, #49525.

+1 on macOS. Running about a dozen scheduled tasks that form the backbone of my personal Cowork setup. Every run re-prompts for file and tool permissions even after hitting "Always allow" on every prompt, across every task.

One additional data point: switching a task's permission mode to Bypass Permissions did NOT resolve it for me. Prompts still appear on scheduled runs. Same thing with ~/.claude/settings.json containing scoped allow rules for the exact paths and tools these tasks touch. Neither layer holds across scheduled sessions.

Duplicate of #3781

Confirming this reproduces on Windows as well — so it's not macOS-specific.

Environment:

• Windows 11
• Claude Desktop (Cowork mode)
• Connected MCPs: Slack, Gmail, Notion, Google Calendar, and others

Symptom: Scheduled tasks re-prompt for folder and tool permissions on every run, despite having previously selected "Always allow." "Always allow" selections do not persist between scheduled task sessions, which makes unattended automation impossible — the whole point of a scheduled task.

Happy to provide additional logs or repro details if useful.

+1 from a Rippling HRIS engineering team. This blocks unattended agentic flows in Cowork — every multi-step task breaks on per-tool re-prompts, so scheduled / overnight runs and long-running handoffs are not viable. Happy to test fixes.

— Posted via AI agent on Nikita's behalf; may contain errors. Tag or DM Nikita if feedback.

+1 on Windows 11 / Claude Desktop. Same root behavior as #30356 but on the broader scheduled-task surface, not just Chrome.

Multiple scheduled tasks per day, all prompting for permissions on every run despite prior "Always allow" selections. The "Always allow" option also appears inconsistently in the prompt UI on scheduled runs (matches #33027).

Net effect across the related issues (#30356, #40470, #47180): scheduled tasks cannot run unattended on any account that uses MCP tools or the Chrome bridge. The scheduling feature works only for pure-LLM tasks with no tool calls, which is a small fraction of real automation use cases.

Would echo the ask in #40470: scheduled task runners should inherit the account's defaultMode + allow rules from settings.json, OR the update_scheduled_task tool should expose permissionMode so users can explicitly bypass per task.

Same here, macOS, only happening for a subset of connectors. In our case, Snowflake tools keep failing to adhere to "always allow" status, while others (e.g. Slack) seem to run smoothly.

Confirming this also affects Claude for Desktop scheduled tasks (separate surface from Cowork), and adding the spawn-side evidence.

Same bug, Desktop surface
Claude for Desktop: 1.6608.2
Bundled CLI (used to spawn scheduled tasks): 2.1.128
macOS: Sequoia, arm64
Scheduler: built-in mcp__scheduled-tasks__*, registry at ~/Library/Application Support/Claude/claude-code-sessions/<workspace>/scheduled-tasks.json
Every task in my registry has "permissionMode": "auto". The field is persisted correctly by mcp__scheduled-tasks__create_scheduled_task. But cron-fired sessions ignore it.

Reproduction in 3 lines
Pull the registry value:

$ jq -r '.scheduledTasks[] | "\(.id)\t\(.permissionMode)"' \
"$HOME/Library/Application Support/Claude/claude-code-sessions/<workspace>/scheduled-tasks.json"
task-a auto
task-b auto
task-c auto
... (11/11 of my tasks → auto)
Pull the same value from the spawned session's transcript metadata:

$ for f in ~/.claude/projects/<workspace>/*.jsonl; do
head -3 "$f" | grep -oE '"permissionMode":"[^"]*"' | head -1
done | sort | uniq -c
38 "permissionMode":"default"
38 of 38 cron-fired sessions in the past 2 weeks ran in default. The only sessions that came up in auto were ones I resumed manually after a desktop restart — on those, ps -o command= confirms --permission-mode auto IS on the CLI command line, so the bundled 2.1.128 CLI handles the flag correctly when given it.

Where the field gets dropped
The SDK transport in app.asar correctly translates options.permissionMode to the CLI flag:

// .../Claude.app/Contents/Resources/app.asar
...permissionMode:l,allowDangerouslySkipPermissions:d,...
l && O.push("--permission-mode", l),
d && O.push("--allow-dangerously-skip-permissions"),
So the bug is upstream of the SDK transport — the desktop's scheduled-task launcher isn't reading permissionMode from the registry record into the spawn options. Field is stored, MCP tool persists it, UI surfaces it, but the spawn call site drops it.

Sister bugs suggest a broader pattern
This looks like the same root-cause family as:

#48976 — scheduled tasks ignore the model setting (registry has Opus, spawn uses Sonnet 4.6)
#39889 — explicitly calls out both model and permission-mode being dropped on dispatch-spawned sessions
If the fix is at the registry → spawn-options bridge in the scheduled-task launcher, fixing it once should resolve all of the above. A unit test would be: create a task with permissionMode: "auto" and model: "claude-opus-4-7", fire it, and assert the spawned process's argv contains both --permission-mode auto and --model claude-opus-4-7.

Suggest adding labels
area:desktop (in addition to area:cowork) since both surfaces share this exact failure.

Concrete failure example
A daily cron-fired task: the first Bash command in the spawned session was a benign export X=...; echo "$(test -f $X)" env-check — would be classified as Local Operations under auto-mode. Got rejected with the standard "user doesn't want to proceed" message. ~26-minute gap until I manually intervened. Transcript available on request.

I'm experiencing the same issue on Windows with Cowork mode. The folder authorization prompt appears every time a scheduled task runs in a new session, even after clicking "Allow for all scheduled runs." Looking forward to an official fix.

I'm also facing this issue with Claude Code on Mac (desktop app). Note that I do not have a bypass permissions mode available on Mac as I do on PC.

Description
When a scheduled task runs and prompts for a tool permission, clicking "Always allow" does not persist the approval to the task's approvedPermissions. The next time the task runs, the same tool prompts again. This contradicts the UI text on the task's detail page, which states "Approvals you grant during a run appear here."

Reproduction:

1. Create a new scheduled task that uses the Claude in Chrome connector. Set fireAt to ~3 minutes from now. Example prompt: "Navigate to https://www.google.com/ using mcp__Claude_in_Chrome__navigate."
2. When the task fires and prompts to allow browser:navigate, click "Always allow". Note the "session" scope tag in the top-right of the prompt.
3. Re-enable / re-run the task.
4. Observe: the same browser:navigate permission prompts again.
5. Inspect ~/Library/Application Support/Claude/claude-code-sessions///scheduled-tasks.json: the task entry has no approvedPermissions field at all (or has not grown).

Expected: "Always allow" during a scheduled-task run adds the tool to that task's approvedPermissions so future runs proceed without prompting.

Actual: The approval is session-scoped only (per the "session" tag) and never written to the task. The "Always allowed" UI section perpetually shows the placeholder text.

Workaround: None working. Editing scheduled-tasks.json directly is reverted by the harness on next run. The mcp__scheduled-tasks__update_scheduled_task API does not expose approvedPermissions or permissionMode. Global settings.json allowlist does not apply to scheduled tasks.

Environment: Claude Code 2.1.128 on macOS

Confirming this on Windows 11 with OneDrive Known Folder Move
Adding cross-platform confirmation that this is not macOS-only.
Environment:

Windows 11
Cowork desktop app, current version as of 2026-05-29
Folder requested: C:\Users\sethm\OneDrive\Documents\Claude\JobSearch (Documents redirected to OneDrive via Known Folder Move)
Prompt button label: "Allow for all scheduled runs"

Reproduction:

Manually trigger any scheduled task that calls request_cowork_directory for the above folder.
Click "Allow for all scheduled runs" on the prompt.
Within the same Cowork session, trigger another scheduled task that uses the same folder.
Same prompt re-appears.

Tested and ruled out (none worked):

~/.claude/settings.json and ~/.claude/settings.local.json with permissions.additionalDirectories containing the OneDrive-canonical path
Same plus the legacy non-OneDrive Documents path (C:\Users\sethm\Documents\Claude\JobSearch — Windows resolves to the same physical location under KFM)
Both escaped (\\) and unescaped (\) path forms
Full Cowork tray-quit and relaunch between attempts
Multiple click-throughs of "Allow for all scheduled runs" within the same Cowork session

Impact:
Four scheduled tasks (two daily top-10 job searches, a weekly summary, and a watchlist alerts task) all stall silently when they fire while I'm away from my desk. Scheduled automation is effectively broken on Windows until this is fixed. I need these tasks to begin while I sleep so the reports are produced before Claude's high-traffic times.
The settings.json approach surfaced in some Anthropic-adjacent docs as a workaround appears to apply only to Claude Code (CLI), not Cowork. If that's intentional, it would help to document that explicitly; if Cowork is meant to honor the same file, that may be a separate companion bug.

Confirming and extending #59302 — "Allow for all scheduled runs" folder grant not persisting

Same bug as #59302, still present on a newer build than the original report. Adding a fresh repro plus scale, since this fully breaks unattended scheduling for me.

Environment

• Claude Desktop (Cowork mode), Version 1.15962.1 (1e236d)
• OS: Windows
• Original report #59302 was on 1.7196.0, so this regression persists past that build.

What's wrong

Every scheduled task that calls mcp__cowork__request_cowork_directory re-prompts for folder access on every run, including automatic scheduled runs. Clicking "Allow for all scheduled runs" does not persist. The task's Always allowed panel stays empty ("Approvals you grant during a run appear here"). Next run, same prompt.

The prompt in question:

Claude would like to Cowork in: C:\Users\<me>\OneDrive - ... \AMW Vault [Deny] [Allow for all scheduled runs] [Allow]

Scale / impact

I run 9 scheduled tasks; 8 of them mount the same OneDrive vault path via request_cowork_directory in their first step (it's the single source of truth they read playbooks from and write outputs to). That means I have to manually approve the identical folder prompt up to 8 times a day for automation that is supposed to run unattended at 5am–7am and 9pm. The one task that doesn't touch the vault is the only one that runs clean.

Steps to reproduce

1. Claude Desktop, Cowork mode.
2. Create a scheduled task whose prompt calls mcp__cowork__request_cowork_directory with a folder path.
3. Click Run now.
4. On the folder prompt, choose Allow for all scheduled runs.
5. Let the task complete successfully.
6. Open the task detail page → Always allowed panel is empty.
7. Run again (manual or scheduled) → same folder prompt reappears.

What I've already ruled out

• Recreating tasks from scratch and re-approving on a fresh run — no change (matches #59302).
• Adding the vault path to permissions.additionalDirectories in ~/.claude/settings.json, plus allow rules — no effect on this prompt. This confirms the Cowork folder-mount approval is a separate system from Claude Code's file-permission allow-list; settings.json does not govern it.
• Version is not the issue: I am already on a build newer than the original report and the bug is fully reproducible.

Expected

After Allow for all scheduled runs, the grant should save to the task's Always allowed panel and all future runs (manual and scheduled) should access that folder without prompting.

Why this matters

This makes unattended scheduling unusable for any workflow that reads or writes a user folder, which is most non-trivial Cowork automations. The folder mount is unavoidable for tasks that write to a vault/Drive, so there is no user-side workaround.

+1 on #47180 — Windows repro, newer build, settings.json and bypassPermissions both confirmed non-working

Adding a Windows data point to this cluster. Same root cause as #47180 / #59302 / #40470 / #24433. The Cowork folder-mount approval for scheduled tasks does not persist, and the documented workarounds do not apply. Posting here because #47180 is the open canonical issue (#59302 was closed as a duplicate).

Environment

• Claude Desktop (Cowork mode), Version 1.15962.1 (1e236d)
• OS: Windows
• This is newer than the builds in #47180 (1.1617.0) and #59302 (1.7196.0), so the regression persists past both.

What's wrong

Every scheduled task that calls mcp__cowork__request_cowork_directory re-prompts for folder access on every run, including automatic scheduled runs. The prompt:

Claude would like to Cowork in: C:\Users\<me>\OneDrive - ...\AMW Vault [Deny] [Allow for all scheduled runs] [Allow]

Clicking "Allow for all scheduled runs" does not persist. The task's Always allowed panel stays empty ("Approvals you grant during a run appear here"). Next run, same prompt.

Scale / impact

I run 9 scheduled tasks; 8 mount the same OneDrive vault path via request_cowork_directory in their first step (it is the single source of truth they read playbooks from and write outputs to). They run unattended at 5am–7am and 9pm. I currently have to be present to approve the identical folder prompt up to 8 times a day, which defeats the purpose. The only task that runs clean is the one that never touches the vault.

Workarounds tried — none work (matches the cluster)

• "Allow for all scheduled runs" on a fresh Run now → not saved, Always allowed panel stays empty.
• ~/.claude/settings.json permissions.additionalDirectories with the exact vault path, plus permissions.allow rules (Read/Write/Edit/Glob/Grep/Bash) → no effect on the Cowork folder-mount prompt. This confirms the request_cowork_directory approval is a separate system from Claude Code's file-permission allow-list; settings.json does not govern it.
• bypassPermissions defaultMode (per the closed-but-persisting #40470) → reported non-working across this cluster; consistent with my result.
• Version: already on a newer build than #47180 and #59302; bug fully reproducible.

Path correctness was verified; this is not a malformed-path issue.

Related issues (same underlying problem)

• #47180 (this issue, open) — macOS, prompts reappear every run
• #59302 — Windows, "Allow for all scheduled runs" not persisting (closed as duplicate)
• #40470 — prompts despite bypassPermissions defaultMode (closed, persists)
• #24433 — MCP "Always allow" does not persist across Cowork sessions
• #33027 — "Always allow" missing from some scheduled task prompts
• #30356 — Chrome extension permission dialog reappears every scheduled run
• #30953 — Desktop should honor managed-settings.json for all permissions

Expected

After Allow for all scheduled runs, the grant should save to the task's Always allowed panel, and all future runs (manual and scheduled) should access that folder without prompting. The scheduled-task runner should inherit account permission settings (defaultMode + allow rules) so unattended automation actually runs unattended.

Why this matters

Any Cowork automation that reads or writes a user folder is affected, which is most non-trivial ones. The folder mount is unavoidable for tasks that write to a vault/Drive, so there is no user-side workaround. This makes scheduled tasks unusable for their primary purpose.

I'm having the same problem, this is beyond annoying when trying to use the Figma MCP server connection. A task that should've been running in the background to take perhaps 40 minutes, took me 6 hours because I had to constantly hit "allow once"

Same root cause showing up in a different surface: Claude Code scheduled tasks (SKILL.md files with dangerouslySkipPermissions: true in frontmatter) have the identical problem, confirmed via direct session metadata inspection rather than inferred.

Compared ~/Library/Application Support/Claude/claude-code-sessions/*/*/local_<id>.json across consecutive automated firings of the same scheduled task:

• nightly-doc-sync, 2026-07-04 firing (session local_88f308ec...): permissionMode: "acceptEdits" — after a manual "Run Now" with prompts approved live.
• nightly-doc-sync, 2026-07-05 firing (session local_7234229a..., brand-new session ID): permissionMode: "default" — reset, despite dangerouslySkipPermissions: true unchanged in frontmatter.
• docs-sync-loop, 2026-07-05 firing (session local_128b1f22...): also permissionMode: "default".

Confirms this isn't Cowork-specific or "Always allow"-specific — it's the scheduled-task session-spawn mechanism itself not carrying forward any prior permission grant, regardless of how that grant was made. Neither create_scheduled_task nor update_scheduled_task expose a parameter to set permission mode directly either, so there's no available workaround at the task-config level.

The invariant I would test here is that scheduled execution must not reconstruct authority from UI memory. It should either carry a versioned approval lease into the spawned session or start in a clearly denied/no-effect state.

A useful regression shape:

1. task record declares desired permission mode and approved tool/path grants
2. scheduler spawns a new session
3. spawned session receives an authority envelope with task id, grant set hash, permission mode, source version, and expiry or revocation marker
4. first mutating/tool call checks against that envelope before prompt fallback
5. if the envelope is absent, stale, or references session-scoped tool ids, the task fails closed with a no-effect reason instead of prompting forever or silently resetting to default

The key split is persistent authorization versus session-local approval. "Always allow for scheduled runs" is not the same as "allow in this session"; it needs a replayable task-scoped grant that survives a new process and can be audited/revoked later.