Codex App heartbeat RRULE with multiple BYHOUR/BYMINUTE occurrences only runs first daily occurrence, then advances next_run_at to next day

Open 💬 0 comments Opened May 18, 2026 by Jas0nla

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?

  1. On Windows Codex Desktop, create a heartbeat automation attached to an existing thread.
  2. Configure the heartbeat RRULE as:
FREQ=DAILY;BYHOUR=11,18;BYMINUTE=0,15;BYSECOND=0
  1. Let the first daily occurrence run, for example around 11:00 local time.
  2. Inspect the automation scheduler state in the local automation database, specifically last_run_at and next_run_at.
  3. Observe that next_run_at advances to the next day rather than to the 11:15 same-day occurrence.
  4. 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.

View original on GitHub ↗