scheduled-tasks: task skipped as 'folder is not trusted' despite project already showing hasTrustDialogAccepted: true

Description

A scheduled task (mcp__scheduled-tasks__*) was skipped at its scheduled fire time with the toast/notification "Scheduled task '<name>' was skipped. The folder is not trusted." — even though the associated project directory shows hasTrustDialogAccepted: true in .claude.json, and an interactive session already running in that exact same directory is not prompted for trust at all.

Repro

1. Have an existing interactive session open and fully trusted in project directory C:\paepos (confirmed via .claude.json → projects["C:\\paepos"].hasTrustDialogAccepted: true, and also present as a second normalized entry projects["C:/paepos"].hasTrustDialogAccepted: true).
2. Have a scheduled task (created via create_scheduled_task, stored at C:\paepos\.claude\scheduled-tasks\<taskId>\SKILL.md) configured to fire automatically (cron 0 8 * * 2,5).
3. Let it fire at its scheduled time.

Expected: the task runs, since the project directory is already trusted (confirmed both by the stored state and by the interactive session in the same directory never being re-prompted).

Actual: a notification appears: Scheduled task "<task name>" was skipped. The folder is not trusted. The task does not run.

Notes / possible cause

.claude.json's projects map has two entries for what should be the same directory — "C:\\paepos" (backslash) and "C:/paepos" (forward slash) — both independently marked trusted. This suggests path normalization is inconsistent somewhere in the app, and it's plausible the scheduled-task runner computes/looks up a third normalized form (e.g. different case, trailing separator, or a \\?\ long-path prefix on Windows) that matches neither stored key, so the trust lookup misses and the run is treated as untrusted and skipped rather than erroring loudly.

Also worth noting: .claude.json is autosaved by the running app roughly every 60 seconds (observed via timestamped backups in C:\paepos\.claude\backups\). This makes any user-side workaround of hand-editing .claude.json to add extra normalized path variants unreliable — the next autosave (from the app's own in-memory state, unaware of the out-of-band edit) silently reverts it. So there's currently no safe way for a user to work around this without direct product access to whatever's driving the scheduled-task trust check.

Environment

• Claude Code CLI 2.1.215, win32 (Windows 11)
• Installed via npm install -g @anthropic-ai/claude-code --prefix ... (standalone CLI), config dir relocated via CLAUDE_CONFIG_DIR to C:\paepos\.claude
• Task entrypoint recorded for the current interactive session: "entrypoint":"claude-desktop"

Impact

Medium — this silently drops scheduled work with no actionable remediation path exposed to the user (no CLI flag or command found to re-establish trust specifically for scheduled/background execution; claude project --help only offers purge, not a trust-repair option). A user could have a recurring task silently stop running indefinitely and have no clear way to notice or fix it beyond happening to see the toast notification live.

Related

Filed alongside #79587 (scheduled-tasks schedule-summary display bug) — found while validating that fix; both surfaced from the same job-search-daily-run task.