[BUG] Scheduled tasks: 3 tools never auto-approved under Bypass permissions, the run hangs and holds a slot

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?

In a local scheduled task (desktop app, Routines → Local), set to Bypass permissions, three tools are never auto-approved:

• mcp__scheduled-tasks__update_scheduled_task
• mcp__scheduled-tasks__create_scheduled_task
• AskUserQuestion

The scheduler logs that it is refusing them on purpose:

2026-09-10 16:44:50 [info] [CCDScheduledTasks] Not auto-approving "mcp__scheduled-tasks__update_scheduled_task" in scheduled task "<task-a>": no suggestions on request
2026-09-10 20:09:17 [info] [CCDScheduledTasks] Not auto-approving "mcp__scheduled-tasks__create_scheduled_task" in scheduled task "<task-b>": no suggestions on request
2026-09-12 17:38:09 [info] [CCDScheduledTasks] Not auto-approving "AskUserQuestion" in scheduled task "<task-c>": no suggestions on request

How this differs from #85820 and #86915. Those report that a prompt in an unattended run never times out. In their cases the stuck tool was a Bash command outside an allow list, and an allow rule fixes it. Here, nothing does:

• the task is already in Bypass permissions;
• allow rules in settings.json change nothing;
• the tools are still offered to the session, so the model can't know the call will hang.

It also used to work better. In May (#60443, closed as stale), these same tools failed at once under bypass/auto with "This tool requires user interaction and is unavailable in unsupervised mode." Today, in scheduled tasks, they hang instead.

For a self-pacing task this is normal behaviour. Twelve of the fourteen refusals below came from one task calling update_scheduled_task to move its own next run.

The run then shows a permission prompt that nobody is there to answer. As described in #85820, there is no timeout. The session stays isRunning and keeps one of the 3 global dispatch slots. Once three runs are stuck like this, every other scheduled task is skipped once a minute:

2026-09-20 12:41:18 [info] [CCDScheduledTasks] Skipping dispatch for <task-d>: global_limit (active=3, limit=3)

What it cost on one machine (Windows, ~20 scheduled tasks):

• Two runs froze on update_scheduled_task on 2026-09-18 at 02:40 and 13:20. Two days later both were still isRunning, even though their task had been deleted in the meantime. They held two of the three slots the whole time.
• The third slot went to a run that froze on the same call at 00:58 and waited until someone clicked at 12:03.
• Blocked dispatch ticks: 0 before 2026-09-18, 71 on the 18th, 577 on the 19th, 1,543 by noon on the 20th. Every task was late or never ran.
• Over four days: 14 "Not auto-approving" refusals and 0 auto-approvals for these three tools. The gate seems to sit in the scheduled-task layer, not in the normal permission system.

What Should Happen?

Any one of these would fix it, in order of preference:

1. In an unattended run, a refused tool fails at once with a tool error the model can read (for example "not available in scheduled runs"). The model then carries on or ends cleanly.
2. Or: don't offer these three tools to scheduled-task sessions at all.
3. Or: if bypass permissions is meant to cover them, honour it.

The general fix in #85820 (a fail-closed timeout for prompts in unattended runs, and freeing the slot while waiting) would limit the damage. But for these three tools the hang is certain every time, so it should not depend on a timeout.

Error Messages/Logs

From %LOCALAPPDATA%\Claude\logs\main.log (task names replaced with placeholders):

2026-09-10 16:44:50 [info] [CCDScheduledTasks] Not auto-approving "mcp__scheduled-tasks__update_scheduled_task" in scheduled task "<task-a>": no suggestions on request
2026-09-10 20:09:17 [info] [CCDScheduledTasks] Not auto-approving "mcp__scheduled-tasks__create_scheduled_task" in scheduled task "<task-b>": no suggestions on request
2026-09-12 17:38:09 [info] [CCDScheduledTasks] Not auto-approving "AskUserQuestion" in scheduled task "<task-c>": no suggestions on request
2026-09-20 12:41:18 [info] [CCDScheduledTasks] Skipping dispatch for <task-d>: global_limit (active=3, limit=3)

Steps to Reproduce

1. Create a local scheduled task with permission mode Bypass permissions. Prompt: "Call update_scheduled_task to change your own description to 'probe', then reply DONE."
2. Let it fire (or Run now) and don't touch the machine.
3. main.log shows Not auto-approving "mcp__scheduled-tasks__update_scheduled_task" … no suggestions on request. The session sits on a prompt and never prints DONE.
4. Do the same with three tasks. Every other scheduled task now logs Skipping dispatch … global_limit (active=3, limit=3) until someone answers the prompts.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.283 (Claude Code) — desktop app 2.19675.0; first seen on 1.52386.6 and 2.110.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Seen with Opus and Sonnet sessions; not model-specific. Windows 11 Home 10.0.26300, Microsoft Store (MSIX) install, Claude desktop app (Code tab).

Related:

• #60443: the same tools failing fast in May (see above).
• #85820 and #86915: the hang and the slot it holds (macOS; per_task_limit there, global_limit here).
• #92753: frozen sessions exhaust global_limit.
• #94643: no permission mode on create.
• #89632: scheduled tasks run under ask-every-tool.
• #91387: make the limit of 3 configurable.

None of these covers the three tools that bypass permissions does not reach.

What we do in the meantime:

• Every task prompt forbids the three calls. A lint check fails if a prompt mentions them.
• A task's next-run timing now lives in a state file, not in its cron.
• A small watchdog (a Windows scheduled task, every 30 minutes) stops any scheduled-task session that has been idle for more than 90 minutes.