[BUG] CronCreate recurring job fires correctly once, then re-fires every 12-37s (regression of #49198 on v2.1.198)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (for this version — closed #49198 covers the same symptom on an older version)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

A recurring cron job created via CronCreate fires correctly once, close to its scheduled interval, then immediately starts re-firing every 12–37 seconds instead of waiting for the next scheduled occurrence. This is the same symptom as closed issue #49198 ("Deleted cron jobs continue firing in infinite loop"), which was reported fixed in v2.1.105. We're seeing it recur on v2.1.198.

One difference from #49198: in our session, CronCreate's own tool description states durable currently has no effect — "all jobs are session-only (in-memory), gone when this Claude session ends." #49198's fix targeted a file watcher missing post-fire cleanup for tasks persisted to scheduled_tasks.json. Since our jobs were never file-persisted (purely in-memory, single session, no --continue/restart involved), the original fix's file-watcher theory doesn't obviously explain this recurrence — it may be a related-but-distinct bug in the in-memory reschedule path, not the file-watcher path #49198 patched.

Environment

• Claude Code version: 2.1.198
• Platform: Linux (WSL2), Linux 6.18.33.2-microsoft-standard-WSL2
• Shell: zsh
• Interface: Claude Code CLI

Steps to Reproduce

1. In a running session, create a recurring cron job with a multi-minute period:

``
CronCreate: cron="*/15 * * * *" prompt="<any prompt>" durable=true recurring=true
``

1. Leave the session idle/active as normal. The job fires correctly the first time, at (or close to) the expected ~15 minute mark (within the documented "up to 10% late" jitter).
2. Continue observing: the SAME job then fires again within seconds — in our reproductions, 12–37 seconds after the previous fire — repeatedly, instead of waiting ~15 minutes for the next occurrence.
3. CronList throughout shows exactly one job registered, with the correct "Every 15 minutes" label — no duplicate/ghost jobs are created. The schedule metadata looks correct; only the actual firing cadence is wrong.
4. Deleting and recreating an equivalent job (new job ID) reproduces the identical pattern: correct first fire, then rapid-refire.

Expected Behavior

• After firing once, a recurring job should wait for its next real cron-matched occurrence (~15 minutes later for a */15 * * * * schedule, plus documented jitter) before firing again.

Actual Behavior

• The first fire after arming respects the cron interval (within jitter).
• Every fire after the first happens 12–37 seconds later, as if the reschedule step is computing the next fire time in the wrong unit (seconds instead of minutes) or not advancing the "next fire" reference at all.

Reproduction Data (this session, 2026-07-06, all times UTC)

Job eb11f922 (*/15 * * * *):
| Event | Time | Gap from previous |
|---|---|---|
| Created | ~09:50:25 | — |
| Fire 1 | 10:06:59 | ~16.5 min (in-spec, matches 15min × 1.1 jitter) |
| Fire 2 | 10:07:21 | 22s |
| Fire 3 | 10:07:33 | 12s |
| Fire 4 | 10:07:46 | 13s |
| Fire 5 | 10:08:19 | 33s |
| Fire 6 | 10:08:37 | 18s |
| Deleted | 10:08:37 | — |

Job 5a81a116 (recreated identically, */15 * * * *):
| Event | Time | Gap from previous |
|---|---|---|
| Created | ~10:08:37 | — |
| Fire 1 | 10:32:57 | ~24 min (elevated but plausibly idle-delayed; still in the "waits for correct interval" category, not a rapid-fire) |
| Fire 2 | 10:33:34 | 37s |
| Deleted | 10:33:34 | — |

Both jobs show the identical shape: exactly one correct interval-respecting fire, then immediate rapid re-fire on the order of seconds. CronList confirmed a single registered job at all times in both cases — this was not duplicate jobs or an external process re-submitting the prompt (verified with the user).

Root Cause (hypothesis, informed by #49198's fix)

#49198 was closed with this explanation from ashwin-ant:

Fixed scheduled tasks re-firing in an infinite loop when the file watcher missed the post-fire cleanup — aged-out recurring and one-shot durable tasks now pin to Infinity instead of recomputing a past fire time every tick.

Given our jobs never touched scheduled_tasks.json (per CronCreate's own description, "session-only," durable had no effect), this looks like the same class of bug — the reschedule-after-fire step failing to compute/pin a real future occurrence and instead falling back to "always in the past, fire again next tick" — but occurring in the in-memory session scheduler, a separate code path from the file-watcher-backed persistence layer #49198's fix addressed. The original fix may not cover this path.

Is this a regression?

Yes — #49198 was closed as fixed in v2.1.105; we're seeing the same symptom on v2.1.198.

Claude Model

Claude Sonnet 5 (claude-sonnet-5)