[BUG] One-shot scheduled task with pending permission prompt vanishes from UI (prompt becomes unanswerable, task dies silently)

[cdatso]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment: Claude Code desktop app, Windows 10 Pro 19045. Local scheduled tasks (Routines).

Summary: When a one-time scheduled task (fireAt) hits a permission prompt during its run, the task auto-disables at fire time and its session window disappears from the Routines sidebar while the prompt is still pending. The prompt becomes invisible and unanswerable; the run dies without any report. Nothing indicates a failure occurred.

Steps to reproduce:

1. Create a one-time scheduled task (fireAt a few minutes ahead) whose instructions include a shell command NOT covered by the allowlist (so it triggers a permission prompt).
2. Let it fire. The session starts and blocks on the approval prompt.
3. Wait a few minutes without answering, or navigate elsewhere: the task entry auto-disables (expected for one-shots) but the running/blocked session ALSO disappears from the sidebar.
4. Result: no window, no way to approve/deny, no completion, no error surfaced. The only traces are side effects the run made before blocking.

Observed: 5 occurrences in one morning (independent tasks). A manually started run ("Run now") of the same instructions keeps its window visible and prompts are clickable — only scheduled fires exhibit the black-hole behavior.

Expected: a blocked session should remain visible (or be surfaced in a "needs attention" state) until the pending prompt is resolved, even after the schedule entry auto-disables; at minimum, a failure record ("blocked on permission X") should be kept.

Impact: unattended automation cannot be debugged; a silently-dead task is indistinguishable from a successful quiet one.

What Should Happen?

Expected: a blocked session should remain visible (or be surfaced in a "needs attention" state) until the pending prompt is resolved, even after the schedule entry auto-disables; at minimum, a failure record ("blocked on permission X") should be kept.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce:

1. Create a one-time scheduled task (fireAt a few minutes ahead) whose instructions include a shell command NOT covered by the allowlist (so it triggers a permission prompt).
2. Let it fire. The session starts and blocks on the approval prompt.
3. Wait a few minutes without answering, or navigate elsewhere: the task entry auto-disables (expected for one-shots) but the running/blocked session ALSO disappears from the sidebar.
4. Result: no window, no way to approve/deny, no completion, no error surfaced. The only traces are side effects the run made before blocking.

Claude Model

No response

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Code desktop app, Windows 10 Pro 19045

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response