Scheduled tasks: "Run now" does not consume the pending one-time fire — the task stays armed and re-runs the same prompt on its timer

Summary

Clicking Run now on a scheduled task executes it, but does not clear or consume that task's pending scheduled fire. A one-time task (fireAt) that has already been run manually still fires again when its timer arrives, re-executing the identical prompt from scratch in a second session.

For one-time tasks this is always redundant work: the prompt has already done its job, and the second run repeats it with no memory that the first run happened.

Steps to reproduce

1. Create a one-time task via the scheduled-tasks MCP tool with a fireAt ~30 minutes in the future.
2. Before that time arrives, click Run now on the task in the Scheduled sidebar.
3. Let the run complete.
4. Wait for the original fireAt to arrive.

Expected: the manual run satisfies the task. A one-time task auto-disables after being run — the tool description for create_scheduled_task states "Task auto-disables after firing" — so the pending fire should be consumed and the task should not run again.

Actual: the task remains armed and fires at its scheduled time, starting a second session that re-executes the same prompt from the beginning.

Impact

This is not just cosmetic — the second run is a full agent session:

• Token cost. Every duplicated run is a complete second execution of the prompt. For research- or build-shaped tasks that is substantial.
• Duplicated side effects. Tasks that touch the world — sending mail, posting, downloading, deploying, writing to a database — can perform the same action twice. A prompt written to be run once is not necessarily idempotent, and the second session has no memory of the first, so it cannot detect that it is a repeat.
• It penalises the recommended workflow. "Run now" is the natural way to start a task immediately and to pre-approve its tool permissions. As it stands, using it means accepting a duplicate run later, so the safe habit is to manually disable the task right after clicking Run — which is easy to forget.

Environment

• Claude Code 2.1.204, desktop app
• Windows 10 Home 19045
• Tasks created via the scheduled-tasks MCP tool (create_scheduled_task, one-time fireAt form)

Note on evidence

This is reported from repeated first-hand use rather than from instrumented logs. Worth flagging for whoever picks it up: list_scheduled_tasks exposes only a single lastRunAt value per task, so the bookkeeping visible through the MCP tool cannot distinguish "ran once" from "ran manually, then fired again" after the fact. A snapshot of 133 one-time tasks on this machine showed none currently sitting enabled: true with a lastRunAt — but since the second fire disables the task, that is exactly what a snapshot would look like either way. The repro steps above are the reliable way to observe it.

Possible fix

Treat a manual run as consuming the pending scheduled fire: on Run now, either disable a one-time task the same way a timed fire does, or record the run against the pending slot so the scheduler skips it.

Related

Other reports of scheduled tasks executing more than intended, though by different mechanisms (scheduler-side dispatch rather than manual runs):

• #81241 — one-time tasks firing early / duplicate-executing
• #82517 — tasks firing multiple times per slot, dropped dedupe key

Workaround

Create the task with neither cronExpression nor fireAt. The tool documents this as "ad-hoc — can only be started manually": the task sits in the sidebar with no timer, so Run now is the only way it ever executes and there is nothing left to double-fire.