Desktop app 2.26454.2 silently switched scheduled task runs from auto to acceptEdits; unattended daily routine hung 13 hours on a permission prompt

Summary

The Claude desktop app auto-updated to 2.26454.2 on October 7 (07:34 local). The next scheduled task run, on October 8 at 07:15, started in acceptEdits permission mode instead of auto. Every scheduled run from October 4 through October 7 had started in auto. Nothing in my configuration changed between those runs.

In acceptEdits mode an unattended run stops on the first Bash command that is not on the allow list and waits for a click. Nobody is there to click. My daily morning routine hung for 13 hours on this prompt:

export DEVELOPER_DIR=/Library/Developer/CommandLineTools && git log --oneline -12 && git status --short | head -20 && cos coord send ...

Ten tool calls in, then silence until I opened the app that evening and found the dialog.

Why this is unacceptable

• My user-level permissions.defaultMode is bypassPermissions. The app's own bypass opt-in (bypassPermissionsModeEnabled) is on. The scheduled run ignored both.
• The scheduled task definition (~/.claude/scheduled-tasks/<id>/SKILL.md, and update_scheduled_task) exposes no permission-mode field. There is no way to pin the mode a routine runs in. The app picks it, and the app changed its pick in an auto-update.
• There was no release note, no in-app notice, and no opt-in. The behavior of unattended automation changed overnight because the app updated itself.
• A stalled unattended run produced no failure and no notification. The run shows as "running" for 13 hours. An unattended session blocked on a human prompt should fail fast and notify, not hang.

This is the third issue I have filed today about an auto-update breaking unattended routines (see #100528 on remote-control environment ids and #100527 on MCP connectors silently expiring). The pattern is the same each time: a daily app update changes a behavior that scheduled or remote sessions depend on, nothing tells the user, and the routine dies quietly. I run my daily brief on these routines. I cannot keep re-diagnosing the platform every morning.

Evidence

Permission mode recorded in each scheduled run's transcript (~/.claude/projects/<project>/<session>.jsonl, permissionMode field), with the app version in effect:

| Run (local time) | permissionMode | App |
|---|---|---|
| Oct 4 | auto | pre-update |
| Oct 5 | auto | pre-update |
| Oct 6 | auto | pre-update |
| Oct 7 07:15 | auto | pre-update (update landed 07:34) |
| Oct 8 07:15 | acceptEdits | 2.26454.2 |

Run status for the task still shows the Oct 8 session as running 13 hours later with no error.

Environment

• Claude desktop app 2.26454.2, macOS (Darwin 27.0.0), Apple Silicon
• Scheduled task created in the Code tab (ccd scheduled tasks), cron 5 7 * * *
• User settings: permissions.defaultMode: bypassPermissions
• Project settings: an explicit permissions.allow list (56 rules at the time of the run)

What I expect

1. Scheduled and other unattended runs honor the user's configured default permission mode, or the task exposes an explicit permission-mode setting. Pick one, but do not leave the mode to an undocumented app default.
2. A change to the permission behavior of unattended runs ships behind an opt-in and a release note. Not in a silent daily update.
3. An unattended run that blocks on a permission prompt fails within minutes and notifies me, instead of sitting in "running" state for hours.

Workaround I had to apply

I mined my last 60 session transcripts for every read-only command and added 48 allow rules to the project settings so the routine's commands stop prompting. That is my time spent on your regression, and it still does not cover Python one-liners, which will prompt again tomorrow.