claude-code - 💡(How to fix) Fix [BUG] create_scheduled_task blocked by permissionMode gate in 1.7196.0 — MCP unusable from cowork / autonomous loops / Claude Code CLI [1 participants]

Summary

In Claude Desktop 1.7196.0 (macOS, built 2026-05-12), mcp__scheduled-tasks__create_scheduled_task and mcp__scheduled-tasks__update_scheduled_task return:

This tool requires user interaction and is unavailable in unsupervised mode.

…in every chat surface where they should be usable: cowork sessions, autonomous-loop fires, Claude Code CLI, and Claude Desktop main-app chats. mcp__scheduled-tasks__list_scheduled_tasks is unaffected (no gate).

Repro

1. Open a fresh cowork session (or autonomous loop, or Claude Code CLI session). Anything where permissionMode is bypassPermissions or auto.
2. Ask the agent to register a new scheduled task via the MCP, e.g.:

   use mcp__scheduled-tasks__create_scheduled_task to register /path/to/SKILL.md as a one-shot, fireAt 2026-06-14T15:00:00Z.

3. Tool errors with the unsupervised-mode message above. Approval popup never renders.

Root cause (from app.asar inspection)

/Applications/Claude.app/Contents/Resources/app.asar contains a hardcoded gate:

function xX(e) {
  return e.permissionMode === "auto" || e.permissionMode === "bypassPermissions"
    ? { decision: "block", reason: "This tool requires user interaction and is unavailable in unsupervised mode." }
    : { decision: "allow" };
}

(A sibling gwe(e) does the same check with pI.Auto || pI.Bypass and a near-identical error string.)

Cowork sessions always run in bypassPermissions. Autonomous loops and Claude Code CLI also default to bypassPermissions / auto. These are exactly the surfaces where programmatic scheduled-task creation is useful. So the gate makes the MCP unusable from every agentic context.

Claude Desktop main-app chats don't load the scheduled-tasks MCP at all, so even when permissionMode is default there, the MCP isn't available.

The tool's own description says calling it "shows the user an approval prompt; go ahead and call it when the request clearly describes a schedule — the approval dialog is the confirmation step." The gate fires before that dialog renders.

Workaround

Edit scheduled-tasks.json directly while Claude Desktop is fully quit (no daemon = no clobber). On next launch the daemon reads the entries and registers them. The daemon's documented "clobbers hand-edits within minutes" behavior is true while running; quitting first lets edits persist.

Suggested fix

One of:

• When permissionMode is bypassPermissions in a foregrounded interactive session, still render the approval popup (the popup is the interactivity step the message claims is missing).
• Auto-relax permissionMode for the duration of just this approval dialog, then restore.
• Document the workaround in the scheduled-tasks docs.

Related issues (different symptoms, same area)

• #46224 — scheduled task with bypass-permissions mode keeps prompting anyway
• #29022 — create_scheduled_task tool not injected on Windows
• #34931 — cannot create from within a scheduled task session
• #56001 — failed to create on UNC path

Environment

• Claude Desktop 1.7196.0 (macOS, built 2026-05-12, ARM64)
• macOS Tahoe (arm64)
• Reproduced on multiple fresh chats 2026-05-13 through 2026-05-19.