Scheduled tasks stall silently on permission prompts (no error, no notification); related unattended-run gaps

Summary

Scheduled tasks (desktop "Routines") stall silently when a run hits a permission prompt: the run's transcript simply ends after the tool_use with no tool_result, no error is surfaced to the model or the user, and notifyOnCompletion: true never fires. From the user's perspective the run just "died". We burned 3 scheduled runs (and hours of a paying Max user's time, on Fable 5 with heavy token consumption) diagnosing what turned out to be documented pause-on-permission behavior, because nothing in the product surfaced it.

Environment

• Claude Code desktop app on macOS (Darwin 25.5.0), Japanese UI
• Model: claude-fable-5 / claude-opus-4-8
• Scheduled tasks created via mcp__scheduled-tasks__create_scheduled_task

Issues

1. Silent stall on permission prompts in scheduled runs. A Bash call needing approval pauses the run, but: the paused state is not communicated (no notification, no entry in the run transcript, task shows lastRunAt as if completed). Expected: surface "paused waiting for approval" to the task list, fire a notification, or (better) allow the model to receive an auto-deny with an explanation so it can report and finish.
2. notifyOnCompletion: true never notified for stalled runs (and their eventual termination). Subscriber session received nothing for 3 runs.
3. No permissionMode / model parameters on create_scheduled_task MCP tool. Docs say tasks have a per-task permission mode and recommend DontAsk for unattended use, but the MCP tool cannot set it; it can only be set in the UI form. Same for model — unattended runs picked Sonnet while the project settings say "model": "opus" (project model setting appears to be ignored by scheduled runs).
4. Docs/UI terminology mismatch (i18n): docs and tool descriptions say the "Scheduled" sidebar section; the Japanese UI calls it 「ルーチン」. Cost us a round of confusion.
5. claude-in-chrome upload_image fails with Unable to access message history to retrieve image in desktop sessions (tested twice with fresh screenshot imageIds) — this breaks the documented capture→upload bridge.
6. screenshot/zoom save_to_disk saves to a path unreachable from the session (not under the project, scratchpad, or any Bash-readable location; the result did not include the saved path either). If save_to_disk is meant for user-message attachments only, the tool description should say so explicitly.

Impact

An automation-heavy user (daily unattended content pipeline) spent an evening and a large token budget on trial-and-error that better error surfacing would have prevented. Please prioritize (1)–(3): unattended workflows are a headline feature, and silent stalls undermine trust in them.