CronDelete reports success but the deleted job reappears in CronList after a session restart

Summary

CronDelete returns success and a subsequent CronList confirms the job is gone. After the session's process restarts (observed across both a full OS reboot and an app-level relaunch), the same job id reappears in CronList output, even though it was never re-created.

Reproduction

1. CronCreate a recurring job, note its id.
2. CronDelete that id. Confirm success.
3. CronList — confirms empty (or does not include the deleted id).
4. Restart the session (observed with both a full machine reboot and an app-level relaunch that kills the underlying process).
5. CronList again — the previously-deleted id is listed as if still scheduled.

Evidence

Observed independently by two different sessions, three separate times in one evening:

• One session's deleted id reappeared once, after a full OS reboot.
• Another session's deleted id reappeared twice — once after an OS reboot, once after a separate app-level relaunch (no OS reboot in between, confirmed via kern.boottime being unchanged across the second event).

Both cases were confirmed via direct, repeated CronList checks immediately before and after the restart, not inferred.

Impact

Since CronCreate/CronDelete/CronList are documented as session-only and in-memory ("gone when Claude exits"), this reappearance is surprising — a deleted job should not be capable of returning in a listing after the owning process has actually restarted. Our workaround has been to treat CronList output as unreliable for liveness/existence and unconditionally delete-then-recreate on every resume rather than trust the listing, but this suggests either a persistence path that isn't documented, or a bug in how job state is reconciled across a process restart.

Environment

Claude Code CLI, macOS (Apple Silicon).