[BUG] Routines stuck permanently after unattended run hits an unanswered permission prompt — "Run now" disabled on all routines, new routines can't be created either

Title

[BUG] Routines stuck permanently after unattended run hits an unanswered permission prompt — "Run now" disabled on all routines, new routines can't be created either

Environment

• Claude Code Desktop app (macOS)
• Plan: Max (5x)
• Two scheduled tasks/routines affected: a daily cron (0 8 * * *) and a weekly cron (0 9 * * 1), both using Bash tool calls (git commands)

Timeline

• 2026-09-02: approved "bypass permissions" mode in an interactive session.
• 2026-09-03, ~08:15 local: the daily routine fired automatically (recorded lastRunAt). Inspecting the run transcript shows it completed its first step, then hit a Bash tool call requiring a permission prompt. The run produced zero output (no files written, no error surfaced to me) — it silently died there.
• Same day: found in the run transcript the actual failure:

``
Tool permission request failed: AbortError: Tool permission stream closed before response received
``
i.e. the routine hit a permission prompt while running unattended, nobody was there to answer it, and the permission stream aborted instead of failing cleanly or falling back to a stored/default decision.

• Since then: "Run now" is disabled/inaccessible on both existing routines, and (as of now) creating a brand-new routine also fails — this is no longer scoped to the two original tasks, it looks like a stuck state in the routines subsystem itself.

What I tried (none of it fixed it)

1. Toggled Settings → Usage → "Usage credits" ON, restarted the app. No change.
2. Turned "Usage credits" back OFF (unrelated once usage-% was confirmed low — 4-5% used, so not a quota issue).
3. Full OS restart. No change.
4. Deleted and recreated both scheduled tasks via the scheduled-tasks MCP tool (delete_scheduled_task + create_scheduled_task), preserving identical prompt/schedule content. Deletion reported archiving 37 and 7 past run sessions respectively. New tasks registered successfully (confirmed via list_scheduled_tasks), but "Run now" is still inaccessible on both.

Hypothesis

The unattended run's permission prompt (for a Bash call) never got a response and the stream aborted rather than terminating the run cleanly. This likely left the routine's server-side run session in a stuck/indeterminate state. This matches the pattern in two already-closed issues:

• #56074 — "no way to stop/cancel a running scheduled session" (closed as not planned)
• #54685 — routines hang on "setting up a cloud container" with no timeout/error (closed as duplicate)

Suspected trigger: approving "bypass permissions" the day before may have interfered with the separate mechanism that's supposed to store/replay tool approvals for unattended routine runs (per the tool description: "Tool approvals granted during a run are stored on the task and auto-applied to future runs"). If bypass-permissions mode and the routine's own approval-storage mechanism don't compose correctly, that could explain why the prompt-and-store flow broke instead of working normally.

Expected behavior ("what should happen")

When a routine's unattended run hits a tool-permission decision it can't get an answer to, it should fail cleanly (or fall back to a stored default) instead of leaving the run in a stuck/indeterminate state. A stuck run should never disable "Run now" on other routines or block creating new ones — each routine should stay independently operable. There should also be a way (UI or API) to force-cancel a stuck run, without needing to delete and recreate the routine.

Impact

• Both existing routines are unusable (can't run manually, presumably won't run on schedule either).
• New routines cannot be created via the UI.
• No user-facing way to inspect or clear the stuck run session (consistent with #56074).

Request

• A way to force-cancel/clear a stuck routine run session (client-side or account-level), independent of the specific task definition.
• Investigation into whether bypass-permissions mode and routine tool-approval storage can get into a bad interaction.