[BUG] Scheduled tasks still ignore permissions.defaultMode on 2.1.204 — #40470 closed as completed but reproduces (locked, cannot comment)

Summary

#40470 ("Scheduled tasks prompt for permissions despite bypassPermissions defaultMode set in settings.json") was closed as completed on 2026-03-29 and the conversation locked as resolved. It still reproduces on 2.1.204. Filing fresh because the locked thread can't take a comment.

Environment

• Claude Code 2.1.204, desktop app
• Windows 10 (19045)
• Claude Max 5x

What happens

Scheduled-task runs still raise permission prompts for MCP tool calls, with every documented pre-approval path already in place:

| 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 + .claude/settings.local.json | permissions.defaultMode: "dontAsk" | still prompts |
| C:\ProgramData\ClaudeCode\managed-settings.json | permissions.defaultMode: "bypassPermissions" | still prompts |
| C:\Program Files\ClaudeCode\managed-settings.json | permissions.defaultMode: "bypassPermissions" | still prompts |
| ~/.claude/settings.json | skipDangerousModePermissionPrompt: true | still prompts |

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 — no persist option, which is #33027. It is delivered simultaneously as a phone push notification, an entry in the Code section of the Claude app, and inline in the calling session.

Possible triage hint: the split is by mutability, not by allow rule

Within this one MCP server, all three tools are listed in the same permissions.allow array, but they do not behave the same:

• mcp__scheduled-tasks__list_scheduled_tasks (read) — runs silently
• mcp__scheduled-tasks__create_scheduled_task (write) — prompts every call
• mcp__scheduled-tasks__update_scheduled_task (write) — prompts every call

So the allow-list is being read and honoured for the read tool. The write tools appear to be gated somewhere above it, keyed on whether the tool mutates state.

Why this isn't just #33027

#33027 is about the missing "always allow" affordance. This is the separate claim #40470 made and that was marked completed: that permissions.defaultMode should be honoured by scheduled runs at all. On 2.1.204 it is not — not from user settings, not from project settings, and not from either managed-settings location, which is the one source that is supposed to win outright.

Worth noting for triage: this is 2.1.204, i.e. before the 2.1.206 per-task-permission-mode change described in #77817. So the "scheduled runs ignore defaultMode" behaviour predates that regression rather than being caused by it — they look like two distinct bugs that produce the same symptom.

Practical impact

A scheduled "dispatcher" session that creates or re-times other scheduled tasks cannot run unattended at all: it stalls on the first write call waiting for a human tap, which defeats the point of scheduling it.

Related

• #40470 — closed as completed, locked; this is the same defect still live
• #33027 — missing "always allow" on scheduled-task prompts (corroborated there)
• #77817 — separate 2.1.206 per-task permission-mode regression