claude-code - 💡(How to fix) Fix [BUG] CronCreate tool's `durable: true` flag silently ignored — task remains session-only with no persistence file written

Summary

The CronCreate tool accepts a durable: true parameter that, per its documented behavior, should "persist to .claude/scheduled_tasks.json and survive restarts." In practice the flag appears silently ignored — the task is created as session-only, no persistence file is written, and CronList reports the task with the [session-only] marker just like any default-recurring/non-durable task.

Reproduction

Invoke CronCreate with durable: true (alongside any valid cron expression, prompt, and recurring: false):

CronCreate({
  cron: "17 9 16 6 *",
  prompt: "<any prompt>",
  recurring: false,
  durable: true
})

Observed in the confirmation message:

*"Scheduled one-shot task b61f1fd0 (17 9 16 6 ). Session-only (not written to disk, dies when Claude exits). It will fire once then auto-delete."

(The confirmation message says "Session-only" despite durable: true being passed.)

Then verify:

# No persistence file at the documented location:
ls -la ~/.claude/scheduled_tasks.json
# → No such file or directory

# Nor at the working-directory equivalent:
ls -la ./.claude/scheduled_tasks.json
# → No such file or directory

# Only the lock file exists (created during cron-create operation):
ls -la ./.claude/scheduled_tasks.lock
# → exists

# CronList reports the task as session-only:
# CronList output: "b61f1fd0 — 17 9 16 6 * (one-shot) [session-only]: ..."

Expected behavior

Per the tool description: durable: true should persist to .claude/scheduled_tasks.json, the task should survive session restart, and CronList should differentiate durable tasks from session-only ones (or at minimum the persistence file should exist on disk for any task created with durable: true).

Actual behavior

• durable: true parameter is accepted without error
• No .claude/scheduled_tasks.json file is written (only the .lock file appears)
• Confirmation message reports the task as "Session-only"
• CronList lists the task with the [session-only] marker, identical to non-durable tasks
• Task does not survive a session restart (as it would not, since nothing was persisted)

The flag appears to be silently dropped somewhere in the implementation between the tool call and the actual scheduler.

Why this matters

For users scheduling reminders that need to survive box crashes, session-end events, claude --continue workflows, or any other process-lifecycle interruption, the durable: true flag is the documented mechanism. When it silently fails, users either:

1. Lose reminders they believe are durable (bad — silent data loss equivalent for time-shifted prompts)
2. Work around it by writing OS-level crontab entries / launchd plists / systemd timers (what I did) — but this requires knowing the flag is broken in the first place, which is only discoverable by post-hoc disk inspection or by losing a reminder

Either way, the silent failure is the worst possible failure mode. Loudly rejecting the flag (e.g., "durable: true not supported on this harness/version") would be strictly better than silent acceptance.

Environment

• Claude Code version: 2.1.131
• Platform: Linux x86_64
• Working directory: a git repo with .claude/ subdirectory and existing .claude/scheduled_tasks.lock
• crontab -l confirms OS-level cron is available as a fallback, but that's not the point — the in-product flag should work

Suggested investigation

• Trace the durable parameter handling between CronCreate invocation and the scheduler write path
• Verify whether the .claude/scheduled_tasks.json write step exists and is being skipped, or whether the path resolution is broken (perhaps writing somewhere unexpected)
• Confirm CronList's "session-only" classification logic — does it differentiate durable vs session-only correctly, or does every cron get marked session-only regardless

Related

This was discovered while trying to schedule a one-month-out reminder that needed to survive a box crash (the host had crashed earlier in the day). Discovery was incidental — the cron was created with durable: true, then disk inspection revealed nothing was persisted. If we hadn't checked, the reminder would have been silently lost on session end.

— AI Team Lead