Codex App heartbeat RRULE with multiple BYHOUR/BYMINUTE occurrences only runs first daily occurrence, then advances next_run_at to next day
What version of the Codex App are you using?
Observed from local Codex Desktop logs/session metadata:
- Codex Desktop package:
OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0 - CLI/app version in session metadata:
0.131.0-alpha.9
What platform is your computer?
Windows, x64.
What issue are you seeing?
A thread heartbeat automation configured with a daily RRULE containing multiple same-day occurrences only fired the first occurrence of the day, then advanced next_run_at to the next day instead of the next same-day occurrence.
This makes a single thread-local heartbeat unreliable for workflows that need two or more daily check-ins in the same conversation, such as a morning report and evening report.
The automation was configured as a heartbeat attached to an existing thread. The relevant schedule was:
kind = "heartbeat"
status = "ACTIVE"
rrule = "FREQ=DAILY;BYHOUR=11,18;BYMINUTE=0,15;BYSECOND=0"
target_thread_id = "<redacted-existing-thread-id>"
Expected daily occurrences from this RRULE are approximately:
- 11:00
- 11:15
- 18:00
- 18:15
However, local scheduler state showed the automation ran at the first same-day occurrence only, then skipped the remaining same-day occurrences.
Observed local SQLite evidence:
id: loa-16-30
name: LOA 日报闭环状态机
status: ACTIVE
rrule: FREQ=DAILY;BYHOUR=11,18;BYMINUTE=0,15;BYSECOND=0
last_run_at_local: 2026-05-18T11:00:41.511-07:00
next_run_at_local: 2026-05-19T11:01:09-07:00
There was no local session evidence for the 11:15, 18:00, or 18:15 same-day heartbeat runs. The target thread's session index also did not update for those expected same-day occurrences.
What is the expected behavior?
For a supported RRULE like:
FREQ=DAILY;BYHOUR=11,18;BYMINUTE=0,15;BYSECOND=0
after the 11:00 occurrence completes, the scheduler should set next_run_at to the next same-day occurrence, around 11:15, not to the next day's 11:00 occurrence.
If the Codex App intentionally supports only a narrower RRULE subset for heartbeat automations, the App should reject or warn on unsupported composite daily RRULE shapes instead of accepting them and silently skipping same-day occurrences.
What steps can reproduce the bug?
- On Windows Codex Desktop, create a heartbeat automation attached to an existing thread.
- Configure the heartbeat RRULE as:
FREQ=DAILY;BYHOUR=11,18;BYMINUTE=0,15;BYSECOND=0
- Let the first daily occurrence run, for example around 11:00 local time.
- Inspect the automation scheduler state in the local automation database, specifically
last_run_atandnext_run_at. - Observe that
next_run_atadvances to the next day rather than to the 11:15 same-day occurrence. - Inspect session files / session index for the target thread and observe no same-day heartbeat run at 11:15 / 18:00 / 18:15.
Actual behavior
The heartbeat ran at approximately 11:00, then next_run_at jumped to the next day's 11:00 window:
last_run_at_local: 2026-05-18T11:00:41.511-07:00
next_run_at_local: 2026-05-19T11:01:09-07:00
The intended same-day 11:15, 18:00, and 18:15 runs did not happen.
Impact
This blocks reliable thread-local recurring workflows where the same conversation needs multiple daily check-ins. In this case, the user wanted one persistent daily-report thread with:
- a midday report around 11:15
- an evening report around 18:00 or 18:15
Creating multiple active heartbeat automations attached to the same thread is also not allowed by the App. Attempting to create another heartbeat for the same thread returned:
This thread already has an active heartbeat automation. Only one automation can be attached to this thread.
Because of that one-heartbeat-per-thread restriction, the workaround was to change the single heartbeat to an hourly :15 checker and gate behavior inside the prompt. That workaround is heavier and less precise than a correctly working composite RRULE.
Related issues / not exact duplicates
This appears related to, but distinct from:
- #18472, which asks for minute-level scheduling support.
- #20517, which covers Windows heartbeat resume failures caused by path prefix mismatches.
- #16938, which covers automations marked Active but not running at all.
This report is specifically about a heartbeat automation accepting a composite daily RRULE, running the first same-day occurrence, and then calculating next_run_at incorrectly by skipping the remaining same-day occurrences.
Additional information
No credentials or private workflow content are required to reproduce this. The issue is visible from the automation metadata alone: accepted RRULE, last run timestamp, and next run timestamp.