[BUG] Scheduled task execution ignores UI-configured permission mode and model settings

Corroborating this — same bug, reproduced independently 3 separate times on my end (Windows 11 Pro, build 10.0.26200, Claude Code Desktop app), most recently with detailed timestamped evidence.

2026-08-20 (most detailed reproduction):

• Set "Bypass permissions" mode the night before via the app UI.
• - A recurring daily scheduled task fired ~07:30 the next morning (session created 07:33:10 local time).
• - - The session's very first tool call (a simple, already-allowlisted shell command) blocked for 359 seconds waiting for manual approval — confirmed by pairing each tool_use block with its matching tool_result in the session's own JSONL transcript.
• - - - The session's own metadata JSON (local_<uuid>.json under the app's session-storage folder) showed permissionMode: "acceptEdits" when inspected afterward — i.e. it started in manual/default mode (not the "Bypass permissions" I had configured). At the time I wasn't sure whether that "acceptEdits" value reflected an automatic app escalation or my own manual fix; the 2026-08-21 update below confirms it's the latter.
• - - - - In total, 6 distinct tool calls stalled 7-360 seconds each before the mode stabilized; every call afterward resolved normally in 1-3 seconds.
• - - - - - This is at least the 3rd time I've hit this exact pattern (also 2026-07-24 and 2026-08-19) — always the same shape: whatever permission mode was configured/last active does not carry over to the scheduled-task-spawned session, which instead starts in manual/default.

Also confirmed: create_scheduled_task / update_scheduled_task (the in-app scheduled-task tools) expose no parameter to explicitly set the permission mode for the spawned session, so there's currently no user-facing workaround beyond being present to click through the first few prompts each morning.

Update, 2026-08-21 — 4th reproduction: Explicitly set "Bypass permissions" the night before specifically to prevent a repeat. The next morning the scheduled run was stalled again; on opening the app the permission toggle was showing "manual", not what I'd set before sleeping — I witnessed this directly. The stalled call this time blocked ~35 minutes (2116s, measured the same way as before via the JSONL transcript). I clicked "Approve" on the pending prompt and manually switched the mode to "auto" myself — which also resolves an open question from my 2026-08-20 report above: the post-hoc permissionMode: "acceptEdits"/"auto" value found in session metadata after these incidents is just my own manual fix being captured, not an automatic app escalation. The metadata file only ever shows current state, not history, so it can't be used to catch the reverted mode — only being there in real time can. 4 for 4 now, always the same shape: a permission mode explicitly configured before an unattended run does not carry over to the session the scheduler spawns.

Happy to share more detail from the transcript/metadata analysis if useful for debugging.

Update, 2026-08-22 — 5th reproduction, strongest evidence yet: This time the stalled command wasn't an ad-hoc/unlisted one — it exactly matched a wildcard rule already in my project's allow-list (PowerShell($word = New-Object -ComObject Word.Application*)). The call still blocked for 3627.9s (~60.5 min), the session's very first PowerShell invocation. This shows the bug isn't "missing allow-list entry" but "the allow-list is bypassed entirely while the spawned session is in manual/default mode" — even a wildcard-matched, pre-approved command still needed a live human click. Confirmed via two independent analyses of the session's own JSONL transcript (tool_use/tool_result pairing across all 90 tool calls, and a type-agnostic timestamp-gap sweep across every log line) — both agree only this one call was a multi-minute outlier; the other 89 all completed in under 17 seconds. Also directly confirmed "permissionMode":"default" recorded in the session log both ~2 seconds after the scheduled task was enqueued and again ~76 minutes later, despite the project's permissions.defaultMode being set to "auto". 5 for 5 now.

Happy to share more detail from the transcript/metadata analysis if useful for debugging.

Corroborating on Windows 11 Desktop as well — same combined symptom (model + permission mode both revert), with a clean before/after timeline.

Setup: A daily recurring local scheduled task (git fetch/log across 3 repo clones, MCP reads, a Python SMTP send, a watermark-file update).

Timeline:

• Manually ran the task once via "Run Now". Confirmed via get_session that it defaulted to claude-opus-5 and manual permission mode (every tool call prompted).
• Opened the task in the Routine editor, explicitly set model to Sonnet 5 and permission mode to "auto". Saved.
• Ran "Run Now" again: get_session now correctly showed model: "claude-sonnet-5", and the run completed with zero permission prompts (auto mode working as configured).
• Next regular cron-triggered fire of the same task (~18 hours later, no edits in between): reverted to claude-opus-5 and manual mode — 12 separate approval prompts for otherwise-routine git/python calls, several of which had already been "Always Allow"-approved in the prior manual run.

So the settings visibly took effect for one manual run, then silently reverted before the next scheduled fire — matching the "acceptEdits"/manual-mode-on-next-run pattern described above.

Additional data point, possibly related to #94455 / #90938: a general Bash wildcard rule added to .claude/settings.json (e.g. Bash(git -C * fetch origin)) also did not suppress the re-prompts on the scheduled fire, even though the exact same command pattern ran cleanly (no prompt) during the manually-triggered runs. The scheduled-run prompts appear as structured/named tool descriptions (e.g. "Fetch exigo-platform from origin") rather than raw Bash command strings, which may be why settings.json's command-string matching doesn't apply to them.

Between this and the several related issues (#78430, #91884, #94455, #90938), this looks like a systemic gap between how scheduled-task "Routine" config (model, permission mode, allow-rules) is persisted/applied versus how it's applied to interactive or manually-triggered runs — not a one-off. Happy to share full session IDs/timestamps if useful for debugging.