Codex Desktop automation ignores timezone for actual cron execution

Summary

Codex Desktop automation UI and actual execution disagree on the cron time when timezone is set in automation.toml.

For this automation, the config says Asia/Shanghai and 08:30, the list UI shows 每天 8:30, but the actual run was delivered at 16:30 CST, which matches 08:30 UTC.

This suggests the schedule display path respects timezone, while the actual scheduler / next-run computation path still interprets BYHOUR and BYMINUTE in UTC.

If this repository is not the owning codebase for Codex Desktop automations, please redirect to the correct tracker.

Environment

• Product: Codex Desktop automation
• Date observed: 2026-06-06 and 2026-06-07
• Local timezone: Asia/Shanghai (CST, UTC+08:00)

Config

Local file:

~/.codex/automations/daily-oblique-morning-card/automation.toml

Relevant fields:

kind = "cron"
timezone = "Asia/Shanghai"
rrule = "FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYHOUR=8;BYMINUTE=30;BYSECOND=0"
status = "ACTIVE"

The timezone field was already present on disk by 2026-06-06 17:21:47 CST.

Expected behavior

• List page shows 每天 8:30
• Detail page shows last / next run around 08:30 CST
• Actual automation thread is created around 08:30 CST

Actual behavior

• List page shows 每天 8:30
• Detail page shows 上次运行时间 今天 16:30 and 下次运行 明天 16:31
• Actual automation thread was created at 2026-06-07 16:30:38 CST

The 16:30 actual run time is exactly what you get if 08:30 is interpreted as UTC and then displayed/executed in Asia/Shanghai.

Evidence

1. Local config source of truth

automation.toml contains both:

• timezone = "Asia/Shanghai"
• BYHOUR=8;BYMINUTE=30

2. Actual delivered automation thread time

From local state DB ~/.codex/state_5.sqlite:

SELECT datetime(created_at,'unixepoch','localtime'), id
FROM threads
WHERE first_user_message LIKE '%Automation ID: daily-oblique-morning-card%'
ORDER BY created_at DESC
LIMIT 5;

Observed latest rows included:

• 2026-06-07 16:30:38 for thread 019ea134-959e-7121-a64c-f62a3d5c297a
• 2026-06-06 16:32:03 for thread 019e9c0f-862b-7691-a896-f936cf44bfeb
• 2026-06-06 08:30:50 for thread 019e9a56-f401-7d92-8def-e640ae6cdc8c

This shows both the earlier expected 08:30 behavior and the later 16:30 behavior.

3. UI mismatch

Observed UI state at the same time:

• automation list: 每天 8:30
• automation detail: 上次运行时间 今天 16:30
• automation detail: 下次运行 明天 16:31

Why this looks like a product bug

The workflow/prompt itself cannot shift the trigger time. The mismatch happens before workflow execution:

• the config on disk is correct for Asia/Shanghai 08:30
• the UI list and actual execution disagree
• the actual execution time matches UTC reinterpretation exactly

So this appears to be a Codex automation scheduling bug, not a workflow bug.

Suspected root cause

Different code paths are using different time bases:

• display/config path respects timezone
• next-run and/or scheduler path ignores timezone and evaluates RRULE in UTC

The extra +1 minute (16:31 vs 16:30) on next run may be a separate rounding / recomputation artifact, but the main bug is the timezone mismatch.

Suggested areas to inspect

• automation detail page next-run computation
• backend scheduler RRULE evaluation when timezone is present
• any normalization layer that converts RRULE to a fire time before applying local timezone
• consistency between list-page rendering and actual scheduler source of truth

Impact

This makes cron automations unreliable for non-UTC users. Even after explicitly adding timezone = "Asia/Shanghai", the automation can still fire 8 hours late while the list UI looks correct.