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

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 21, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] 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_

View original on GitHub ↗