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

[aabajabaa]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Cowork scheduled tasks repeatedly prompt for folder/tool permissions on every run, even after selecting "Always allow." The permission does not persist between scheduled task sessions.

Context:
I have 6 scheduled tasks in Cowork (price checkers on Amazon.sa, a market crash scanner, and a Gmail action items task). All tasks post results to Slack via the Slack MCP connector. Every time a scheduled task runs, it re-prompts for folder access and tool permissions, even though I have previously selected "Always allow."

What I tried (none of these resolved the issue):

1. Clicking "Always allow" on every permission prompt during manual "Run now" — permissions do not persist to the next scheduled run.
2. Creating ~/.claude/settings.json with explicit allow rules:

{
  "permissions": {
    "allow": [
      "WebSearch(*)",
      "WebFetch(*)",
      "Read",
      "Write",
      "Edit",
      "Glob",
      "Grep",
      "Bash(curl:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(mkdir:*)",
      "mcp__slack__*",
      "mcp__gmail__*"
    ]
  }
}

3. Restarting Claude Desktop after applying settings — still prompts on every scheduled run.

Related closed issue: #40470 was filed for the same problem and is now closed, but the issue persists on macOS. Issue #30356 (Chrome browser permissions) and #33027 ("Always allow" missing from scheduled task prompts) also describe the same underlying problem.

Environment:

• macOS (Mac Mini)
• Claude Desktop (latest version as of April 2026)
• Claude Cowork with scheduled tasks
• Connected MCPs: Slack, Gmail
• Plan: Paid plan (Pro/Max)

What Should Happen?

Scheduled tasks should respect the user's "Always allow" permission selections and ~/.claude/settings.json allow rules. Once a user grants "Always allow" for a tool or folder, subsequent scheduled runs should execute without re-prompting.

The scheduled task runner should inherit the account's permission settings (including defaultMode and allow rules), enabling unattended automation — which is the entire purpose of scheduled tasks.

Error Messages/Logs

No specific error message — the issue is behavioral. Each scheduled task run displays permission prompts such as:

"Allow Claude to access [folder path]?"
"Allow Claude to use [tool name]?"

These prompts appear on every run despite previously selecting "Always allow." The task stalls until the user manually clicks "Allow," defeating the purpose of scheduled automation.

Steps to Reproduce

1. Create a scheduled task in Cowork (e.g., a daily price checker that uses WebSearch, WebFetch, and posts to Slack via the Slack MCP connector).
2. Run the task manually using "Run now."
3. When permission prompts appear, select "Always allow" for each one.
4. Wait for the next scheduled run (or click "Run now" again).
5. Observe that the same permission prompts reappear, despite having selected "Always allow" previously.

Additional attempt:
6. Create ~/.claude/settings.json with explicit allow rules (WebSearch, WebFetch, Read, Write, mcp__slack__, mcp__gmail__, etc.).
7. Restart Claude Desktop.
8. Run the scheduled task again — permission prompts still appear.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.1617.0 (8d6345) 2026-04-09T16:10:15.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related issues (all describe the same underlying problem):

• [BUG] Scheduled tasks prompt for permissions despite bypassPermissions defaultMode set in settings.json #40470 — Scheduled tasks prompt for permissions despite bypassPermissions defaultMode set in settings.json (now closed, but issue persists)
• Claude in Chrome: browser permission dialog reappears on every scheduled task run #30356 — Chrome extension permission dialog reappears on every scheduled task run
• Scheduled tasks: 'Always allow' option missing from permission prompts #33027 — "Always allow" option missing from scheduled task permission prompts
• [BUG] Claude Desktop Cowork: "Always allow" for MCP tools does not persist across sessions #24433 — "Always allow" for MCP tools does not persist across Cowork sessions
• Claude Code Desktop should honor managed-settings.json for all permissions #30953 — Claude Code Desktop should honor managed-settings.json for all permissions

Scheduled tasks affected (all exhibit this behavior):

• 4x Amazon.sa price checkers (Kindle Colorsoft, Kindle Paperwhite Signature, EPSON L3252, Logitech MX Master 4) — use WebSearch/WebFetch + Slack MCP
• 1x Market Crash Scanner — uses WebSearch + Slack MCP
• 1x Gmail Action Items — uses Gmail MCP + Slack MCP

Impact: Scheduled tasks are effectively unusable for unattended automation, which is their primary purpose. The user must be present to click "Allow" on every run.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Scheduled tasks prompt for permissions despite bypassPermissions defaultMode set in settings.json #40470
2. Scheduled tasks: 'Always allow' option missing from permission prompts #33027
3. [BUG] Claude Desktop Cowork: "Always allow" for MCP tools does not persist across sessions #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

[nic-astro]

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.

2. 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.

[marceloweuller]

+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.

[sciascia]

+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.

[sanchomuzax]

Similar problem.

[amfenix]

Same problem, make cowork unusable right now.

[renehasp]

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

[kayakyakr]

+1. Completely discards the functionality.

[judahsassistant-jarvis]

+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.