Scheduled task `cwd` is locked at creation, silently skips when not in trusted-folder list, no MCP path to fix

Preflight Checklist

• [x] Searched existing issues. Related: #38621 (closed-stale, no delete_scheduled_task), #52839 (worktree durable-cron loss, macOS), #47797 (storage location). This issue is about a different failure mode: silent trust-check skip + no in-tool path to fix.
• [x] Single bug report.
• [x] Claude Code 2.1.119 + Claude Desktop 1.4758.0.0 on Windows 11.

What's wrong

The mcp__scheduled-tasks__* tool surface stores cwd for each task, locked at creation, with no way to inspect or change it via MCP. When that cwd happens to be outside the trusted-folder list in ~/.claude.json (hasTrustDialogAccepted: true), every fire of the task is silently skipped with "the folder is not trusted" — no notification, no entry in list_scheduled_tasks, just a skipped run.

The recovery path is undocumented and brittle: edit AppData\Roaming\Claude\claude-code-sessions\<id>\<id>\scheduled-tasks.json directly, then restart Claude Desktop. Any update_scheduled_task call between the edit and the restart writes the still-stale in-memory state back to disk and reverts the fix.

Repro (Windows)

1. From Claude Code, cd into a git worktree or sub-project that is NOT in the trusted-folder list. Confirm pwd ≠ project root.
2. Ask Claude to create a scheduled task: mcp__scheduled-tasks__create_scheduled_task with any cron.
3. Inspect scheduled-tasks.json — the new entry's cwd is the worktree/sub-project, not the trusted parent.
4. Wait for the scheduled fire. The harness logs "the folder is not trusted" and skips. list_scheduled_tasks does not surface the skip; lastRunAt may equal lastScheduledFor (instant skip) or remain absent.
5. Try to fix via update_scheduled_task — there is no cwd parameter.
6. Try to delete and recreate — there is no delete_scheduled_task tool. create_scheduled_task with the same taskId returns A scheduled task with ID "<id>" already exists.
7. Edit scheduled-tasks.json directly; verify cwd is corrected. Then call update_scheduled_task for any field — disk is reverted to broken state.
8. Only path that works: file edit → close all Claude Desktop windows → reopen.

What should happen (one or more of these)

1. Add cwd parameter to create_scheduled_task and update_scheduled_task. Default to current session cwd on create; explicit override on update.
2. Surface cwd in list_scheduled_tasks output. Currently invisible.
3. Add delete_scheduled_task. Closes #38621 too.
4. Fail loudly on trust-check skip. Emit a notification, set a lastSkipReason field on the task, or refuse to schedule the task at create-time if its cwd is not trusted.
5. Reload scheduled-tasks.json from disk on every operation (or on a refresh tool) so manual edits survive without a Desktop restart.

Real-world impact

Hit this 2026-04-27 with 4 production-critical scheduled tasks (anomaly-followup, weekly-product-noah-review, weekly-friction-mining, decision-quality-tracker) that had been silently skipping for days. Discovery only happened because the user noticed a missing morning report. Recovery took ~45 min of debugging because the failure mode was undocumented and any attempt to fix via MCP reverted itself.

Related

• #38621 — delete_scheduled_task (closed-stale; fixing this would also help recovery here)
• #52839 — durable cron + worktree loss (macOS, different mechanism, same area)
• #47797 — scheduled-tasks.json location

Logs

Trust-check failure does not appear in any user-visible log surface. The lastRunAt timestamp updates on the skip, which is misleading — it looks like the task ran. The only way to detect the skip is to watch for the absence of expected side effects (e.g., the followup file the task should have written).