Permission requests in unattended scheduled-task sessions hang for days with no timeout, wedging the task queue

Summary

When a session spawned by a Claude Code scheduled task hits a permission request, the request never times out. The session sits in "Needs input" indefinitely — for days, not seconds — and while it waits it holds the scheduled task's execution slot, so every subsequent cron fire queues behind it. When the stall is finally cleared by a human, the queued fires drain as a burst.

There is no timeout, no fail-closed path, and no notification that an unattended task has silently stopped doing its job.

Evidence (one production task, July 2026)

• The task is an unattended workflow on a 15-minute cron during a daily window, making time-sensitive external API calls.
• Over a two-week stretch it logged nine distinct permission hangs. The two longest sat pending for 38 hours and 73 hours — spanning multiple days and a weekend — before being resolved manually via remote control.
• Measured task uptime over that stretch: 16.9% (completed fires vs scheduled fires).
• Each stall wedged the dispatcher: subsequent fires did not run at all until the pending request was resolved, after which several queued cycles executed back-to-back within a minute (observed: ~8 cycles inside 30 seconds).
• Because the calls are time-sensitive, a request that surfaces days late guards an action that is already stale — approving it at that point would be actively harmful, so the hang converts "ask the human" into "silently do nothing, then offer the human a footgun."

Why this is not #51339

#51339 framed this as transient ("retry always succeeds") and was auto-closed as stale/not_planned. The behavior above is not transient: a pending request survives for days with no retry ever occurring, and the failure compounds — slot held → queue wedged → burst on release. The distinction matters because the transient framing is what got the prior report closed.

Expected behavior

1. A permission request raised in an unattended context (scheduled-task run, remote-dispatched session) should have a configurable timeout that defaults to fail-closed: deny the request, log it, end the run cleanly, and surface a notification.
2. A session pending on a permission request should not silently hold the scheduled task's execution slot indefinitely. At minimum, the scheduler should surface that fires are queuing behind a pending request instead of letting the task appear healthy while doing nothing.

Environment

• Claude Code desktop app, macOS
• Scheduled task (in-app scheduler), 15-minute cron, sessions run fully unattended
• Observed July 14–27, 2026; reproduced across many fires — any non-allowlisted command in an unattended session reproduces it