›_ Codex Issues
Codex Issues / #16410

Weekly automation RRULE ignores additional BYHOUR values

Open 💬 2 comments Opened Apr 1, 2026 by lukaskral

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.325.31654 (1272)

What subscription do you have?

enterprise

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Summary

Codex automations appear to ignore additional BYHOUR values when using a weekly RRULE.

A rule intended to run multiple times per weekday:

FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8,12,16;BYMINUTE=0

was scheduled as if only the first hour (8) mattered.

Expected behavior

Given the current local time:

  • 2026-04-01 09:46 CEST

the next run for this RRULE should be:

  • 2026-04-01 12:00 CEST

because 12:00 and 16:00 are still upcoming today.

Actual behavior

The automation UI reported the next run as:

  • 2026-04-02 08:00 CEST

The persisted automation state also stored next_run_at for tomorrow morning rather than today at noon.

Environment

  • Codex desktop app
  • Local timezone: Europe/Prague
  • Observed at: 2026-04-01 09:46 CEST

Notes

As a workaround, I had to split the automation into three separate weekday automations:

  • BYHOUR=8
  • BYHOUR=12
  • BYHOUR=16

This suggests either:

  • multi-value BYHOUR is not supported for weekly rules, or
  • it is intended to be supported but the scheduler/UI computes next_run_at incorrectly.

What steps can reproduce the bug?

  1. Create or edit an automation.
  2. Set the schedule to:

FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8,12,16;BYMINUTE=0

  1. Check the “next run” value during a matching weekday after the first scheduled hour but before later scheduled hours.
  2. Observe that the next run is calculated as the next day’s first slot instead of a later slot on the same day.

What is the expected behavior?

Given the current local time:

  • 2026-04-01 09:46 CEST

the next run for this RRULE should be:

  • 2026-04-01 12:00 CEST

Additional information

_No response_

View original on GitHub ↗

2 Comments

ealdent · 3 months ago

Adding current-version confirmation. This still reproduces on Codex App 26.506.31421 (bundle 2620), CLI/app-server 0.130.0-alpha.5, macOS 26.5 (25F71) on arm64, timezone America/New_York.

Configured RRULE:

RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=4,6,8,10,12,14,16;BYMINUTE=0;BYSECOND=0

Observed on Wednesday, May 13, 2026 around 12:39 PM EDT. Expected next run was Wednesday, May 13, 2026 at 2:00 PM EDT, because later BYHOUR slots were still available that day. Actual UI/state showed Thursday, May 14, 2026 at about 4:00 AM EDT. The persisted SQLite value was next_run_at = 1778745708000, which is 2026-05-14T04:01:48-04:00 after the built-in jitter.

I also tried an hourly RRULE as a workaround:

RRULE:FREQ=HOURLY;INTERVAL=2;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8,10,12,14,16,18,20;BYMINUTE=0;BYSECOND=0

That did persist the desired next run for the current EDT offset (2026-05-13T14:01:59-04:00), but manually running the automation then caused Codex Desktop to hang with the macOS beachball until force quit. Restoring the weekly RRULE made manual Run work again. That hang may be a separate issue, but it means the only safe workaround I found is still to split the schedule into separate single-hour automations.

belliez · 3 months ago

I’m seeing the same issue on Windows with Codex desktop automations.
I tried to schedule an email triage automation to run daily at multiple times:

RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16,17,18,19;BYMINUTE=0;BYSECOND=0

The UI collapsed/reverted this to Daily at 09:00, and the additional BYHOUR values were not usable.
Current workaround is to create one separate automation per hour, but this clutters the automation list and makes the task harder to maintain.