[BUG] create_scheduled_task has no permission-mode parameter, so MCP-created tasks always stall unattended

Summary

mcp__scheduled-tasks__create_scheduled_task has no parameter for permission mode, and tasks it creates default to permissionMode: "default" — per-step human approval. Since a scheduled task runs unattended by definition, this means every task created programmatically is born unable to do its job: the first tool call needing approval either aborts (Tool permission request failed: AbortError) or hangs waiting for a human who isn't there.

Combined with the fact that such a run still reports succeeded (filed separately), the task can sit there for weeks appearing to work.

Reproduction

1. Create a task with create_scheduled_task — the tool schema has no permission-mode field, so there is no way to set it at creation.
2. Let it fire unattended.
3. Read the run metadata: permissionMode is "default".
4. Read the transcript: the run stops at the first tool call requiring approval.
5. Check the Runs pane: succeeded.

Verified on a freshly created task: its first run stopped on its very first Bash call, waiting for an approval nobody was there to give.

update_scheduled_task has the same gap

There is no way to fix it programmatically either. The only ways we found:

• Open the task's detail page in the app → Edit → change permission mode. This persists.
• Or click "always allow" on each prompt during a "Run now". This did not persist — comparing permissionMode across a given task's run metadata over time, tasks that had been granted per-tool "always allow" were back to "default" on a later run. (Three tasks, observed over several days. I can't fully characterize when it reverts, but the Edit-dialog setting held where the per-tool grants did not.)

So the only reliable fix requires a human in the GUI, per task.

Why this matters more than a missing convenience flag

The whole point of a scheduled task is that no one is watching. A creation API that can only produce tasks requiring a human at every step, with no way to change that from the same API, means automation built on this MCP surface cannot actually be automated — and the failure is silent.

Expected

Either:

• Add a permission-mode parameter to create_scheduled_task / update_scheduled_task, or
• Default programmatically created scheduled tasks to a mode appropriate for unattended execution, or
• At minimum, have create_scheduled_task return a warning that the task will stall unattended until a human changes the mode.

If there are MCP tools that intentionally always require interaction (we saw this with browser-driving tools, which never offered "always allow"), documenting that would help too — a task that depends on one of those can never run unattended, and knowing that up front would save building it at all.

Environment

• Claude Code Desktop app (macOS 26.5), CLI 2.1.263
• Local scheduled tasks created via the scheduled-tasks MCP tools

Related: #91724 reports what this looks like from the user side — routines wedged on unanswered permission prompts.