Scheduled/unattended task sessions sometimes ignore autonomous-execution instructions and wait for a human instead

Scheduled/unattended task sessions sometimes ignore the autonomous-execution instructions and wait for a human instead

Summary

A scheduled task session (fired via the in-app scheduler — Routines → local scheduled tasks, the kind backed by ~/.claude/scheduled-tasks/<name>/SKILL.md) occasionally receives its full task prompt, wrapped in the standard <scheduled-task> autonomous-execution instructions, and responds as though it's an empty chat waiting for the user to say something — doing zero tool calls and producing zero output. The session is then reported as "status": "succeeded" by list_task_runs, which is incorrect: nothing ran.

This is distinct from a crash or a timeout. The model received a complete, well-formed, explicitly autonomous instruction and chose not to act on it.

Environment

• Claude Code (desktop app), Windows 11
• Observed CLI version in recent session metadata: 2.1.281
• Scheduled-task model in recent runs: claude-opus-5-5 (not confirmed for the two historical instances below, which may have run on an earlier build/model)

Reproduction (two independent, confirmed instances)

Instance 1 — monthly-deep-audit task, 2026-09-01
Session local_5bf99678-aed2-450c-b2f6-dfea5b48e905, started 2026-09-01T00:07:40Z. Full transcript (2 messages total):

[user] <scheduled-task name="monthly-deep-audit" file="...monthly-deep-audit\SKILL.md">
This is an automated run of a scheduled task. The user is not present to answer questions.
For implementation details, execute autonomously without asking clarifying questions — make
reasonable choices and note them in your output. ... [full multi-step audit prompt follows]
</scheduled-task>
[assistant] I'm ready to help. What would you like to work on?

Zero tool calls. No report written. Run marked "succeeded".

Instance 2 — weekly-health-check task, 2026-09-28
Session local_8c774a7d-ab9e-4819-a418-eea5a6352f51, started 2026-09-28T00:02:15Z. Full transcript (2 messages total):

[user] <scheduled-task name="weekly-health-check" file="...weekly-health-check\SKILL.md">
This is an automated run of a scheduled task. The user is not present to answer questions.
For implementation details, execute autonomously without asking clarifying questions ...
[full health-check prompt follows]
</scheduled-task>
[assistant] I don't see a specific task or question in your message yet — just system context
loaded. What would you like me to help with?

Zero tool calls. No report written. Run marked "succeeded".

Expected behavior

Given a <scheduled-task>-wrapped prompt that explicitly states "execute autonomously without asking clarifying questions," the session should act on the enclosed instructions. If it genuinely cannot proceed (ambiguous instructions, missing file, etc.), it should say so in its final output — not treat the entire wrapped block as inert context and wait for a follow-up message that will never come, since no human is present in an unattended run.

Actual behavior

In both instances, the model treated the full task description as background/context rather than as the instruction to act on, and ended its turn asking a clarifying question — which an unattended scheduled run can never answer. The run then reports as "succeeded" with no indication anything is wrong.

Impact

Both instances are from the same local scheduled-task system, across two different task definitions, roughly four weeks apart — not a one-off fluke. Combined with the fact that list_task_runs/the scheduler report these runs as "succeeded," this produces fully silent failures: no error surfaces anywhere, and the only way to detect it is to manually read the session transcript. In our case this went undetected for ~4 months across two recurring tasks before a manual investigation surfaced it.

Notes / what we've ruled out

• Not a prompt-wording issue: both prompts already stated plainly ("execute autonomously without asking clarifying questions") that no human would respond.
• Not related to a separate issue we also found in the same system, where scheduled sessions can hang indefinitely on an unanswered tool-permission prompt (PowerShell/Bash calls sitting unresolved for 9+ minutes until manually interrupted) — that's a different failure mode (the model does try to act, but the session can't get permission approval). This report is specifically about the model not attempting to act at all.
• "status": "succeeded" being reported for a run that did zero work is itself worth fixing independently of the root cause above — at minimum, a run with zero tool calls and no assistant action beyond a clarifying question shouldn't be indistinguishable from a run that did real work.

Suggested fix directions (not prescriptive — flagging options, not requesting a specific one)

1. Make the scheduled-task harness more forceful about signaling "this is not a chat turn, there is no one to answer" — e.g. a system-level (not user-turn) marker rather than embedding the instruction inside a <scheduled-task> user message, which the model can apparently still interpret as conversational.
2. Have the scheduler itself detect a "zero tool calls + ended in a question" pattern and flag the run as failed/needs-attention rather than succeeded.
3. Surface scheduled-task non-engagement as a distinct, visible status in the Routines UI so it doesn't require manual transcript archaeology to catch.