Scheduled task runs intermittently ignore the queued task prompt and greet instead of executing

Description

A local scheduled task's queued prompt (the SKILL.md content) reliably lands in the session transcript, but on some runs the model's first turn ignores it entirely and responds with a generic conversational opener instead of executing the task — as if the turn started a blank interactive session rather than processing the queued message.

This is intermittent, not deterministic: on the same scheduled task, with an unchanged SKILL.md, some runs execute correctly end-to-end and others no-op with a greeting. There is no error, warning, or non-zero exit surfaced anywhere — the task "completes" (a session file is written, lastRunAt updates) having done nothing.

Reproduction (as observed)

Task: a local recurring scheduled task (cronExpression: "0 4 * * 1-5") whose prompt is a large (~7.5KB) SKILL.md file with explicit imperative instructions (e.g. "File without asking... there is no interactive mode").

Comparing 4 consecutive weekday runs of the same task:

• 2 runs (2026-08-05, both queued that day): the model correctly parsed the scheduled-task wrapper + full SKILL.md body as its instructions, executed every step (login, sweep, grade, file a card, close a worklog entry), and produced a proper sign-off summarizing what it did.
• 2 runs (2026-08-06 and 2026-08-07): the transcript shows the identical wrapper format —

``
<scheduled-task name="..." file="...">
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...
# <task title>
...full SKILL.md body...
``

as the first user message, immediately followed by the harness's own attachment deltas (deferred-tool-list, agent-listing, mcp-instructions, skill-listing) — but the first assistant turn is a bare, content-free greeting, e.g.:

> "Hey — what would you like to work on? A few things stand out from the current state: ..."

or

> "I'm ready to help. What would you like to work on?"

The assistant never engages with any instruction in the scheduled-task message — no acknowledgement of the task name, no attempt at step 1, nothing. The session then just sits there (no user is present to reply), and the scheduled task is recorded as having run.

What this rules out

• Not a prompt-content problem. The exact same SKILL.md, unedited, produces correct execution on other runs in the same week. The prompt text is unambiguous and includes an explicit "don't ask, just do it" directive from the scheduled-task wrapper itself.
• Not a permission-prompt hang. Those hang forever with a live process stuck on a tool call; this instead completes normally after a single vacuous assistant turn, so it's a different failure mode from the known stdio-permission-prompt-hang issue.

Impact

Silent, undetectable partial failure of scheduled/automated tasks: roughly half of recent runs of one such task did nothing, with no error signal distinguishing them from successful runs except manually reading the transcript. For any unattended automation (which is the entire point of scheduled tasks), this means results can't be trusted without manually auditing every run.

Environment

• Claude Code Desktop app, local scheduled tasks feature (~/.claude/scheduled-tasks/<taskId>/SKILL.md, managed via the scheduled-tasks MCP tools)
• macOS (Darwin), Claude Sonnet 5 model pinned via SKILL.md frontmatter (model: claude-sonnet-5)
• Task cron: 0 4 * * 1-5 with a small jitter

Suggested investigation

Whatever assembles the initial context for a scheduled-task-triggered session (the ordering/merging of the queued task message with the deferred-tool-list / agent-listing / skill-listing "attachment" system deltas) appears to race or drop the actual task content from what's sent to the model on the affected runs, even though it's written correctly to the transcript file for display purposes. Suggest auditing whether the transcript write and the actual API request payload can diverge — i.e. whether the displayed "attachment" deltas are back-filled into the log after the fact rather than reflecting what the model call actually received.