Desktop scheduled tasks: runs freeze silently after first MCP tool results; re-armed one-time fireAt never fires

Environment

• Claude Code 2.1.193, desktop app on macOS 26.5.1 (Darwin 25.5.0)
• Tasks created via the bundled scheduled-tasks MCP (create_scheduled_task / update_scheduled_task), stored under ~/.claude/scheduled-tasks/

Bug 1 — scheduled run freezes silently mid-run (2/2 reproductions)

Steps:

1. create_scheduled_task with fireAt ~2 minutes in the future. Prompt: a few MCP connector reads (a Slack canvas read, a Notion page fetch) followed by one Slack message send. notifyOnCompletion: true.
2. The task fires on time; a session transcript appears under ~/.claude/projects/<project>/.
3. The session executes its first batch of tool calls and their results land in the transcript (~18–23 events, ~90 KB) — then the transcript never advances: no further assistant turn, no error, no completion or failure notification, and the final send step is never reached.

Observed twice in one evening (9 Aug 2026, runs at 19:24 and 20:16 local), both freezing within ~15 s of start at the same point — immediately after the first tool_result events landed. The Scheduled UI shows nothing abnormal afterwards, so a died run is indistinguishable from a quiet success unless you manually read the transcript files.

Expected: the run completes, or fails loudly and triggers the completion/failure notification.

Bug 2 — update_scheduled_task with a new fireAt on an already-fired one-time task never re-fires

1. A one-time task fires (and auto-disables, as documented).
2. update_scheduled_task with a new future fireAt → the tool result says the task is re-armed, and list_scheduled_tasks shows enabled: true with nextRunAt at the new time.
3. The time passes; nextRunAt sits in the past untouched, no run happens, no lastRunAt is stamped. A freshly created task with an identical prompt and a comparable fireAt fires normally in the same period.

Expected: either the new fireAt fires, or the update call errors/warns that a fired one-time task cannot be re-armed.

Impact

Unattended scheduled work can silently no-op in two different ways: "armed and enabled" can mean "will never run", and a mid-run death produces no signal at all. Both defeat the purpose of scheduling, and both fail in the worst direction — looking exactly like a quiet success.

🤖 Generated with Claude Code