Automation schedules display local time but calculate next_run_at as UTC, causing a 9-hour delay

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

26.707.31428 (5059) CLI: 0.144.0-alpha.4

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm macOS time zone: Asia/Tokyo

What issue are you seeing?

Codex automations created on macOS in the Asia/Tokyo time zone are sometimes displayed using the requested local wall-clock time, while the actual next run is calculated as if the same hour were UTC. This causes the automation to run nine hours late.

I reproduced this with both heartbeat-style and cron-style automations.

First incident:

• Requested run time: July 10, 2026 at 18:45 JST
• Creation time: July 10, 2026 at 17:42:55 JST
• Requested time in UTC: July 10, 2026 at 09:45 UTC
• DTSTART;TZID=Asia/Tokyo:20260710T184500 was rejected with:

Immediate automation creates cannot include DTSTART because it may change local wall-clock times to UTC. Omit DTSTART, or retry with mode=suggested_create when the user intentionally requested anchored or timezone-specific RFC semantics.

• I followed the suggestion and created the automation without DTSTART, using an 18:45 wall-clock recurrence with COUNT=1.
• The stored next_run_at was 1783709100000.
• That timestamp is July 10, 2026 at 18:45 UTC, or July 11, 2026 at 03:45 JST.
• The automation did not run at 18:45 JST, and last_run_at and the run history remained empty.

Second incident:

• Requested run time: July 11, 2026 at 11:00 JST
• The Automations UI displayed: Daily at 11:00 AM
• At 10:18 JST, the same UI displayed: Next run in 10 hours
• The next run should have been approximately 42 minutes away.
• A ten-hour countdown is consistent with 11:00 being interpreted as UTC, which would be 20:00 JST.

Updating the existing automation with an explicit Asia/Tokyo start time did not fix the actual next-run calculation. The saved configuration contained the time zone, but the UI still showed a next run approximately nine hours too late.

This is particularly dangerous because the displayed schedule looks correct while the countdown and actual execution time are wrong.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f4ec9-3e11-7b20-b1fc-e886f763c0ba

What is the expected behavior?

When an automation is scheduled for a wall-clock time in Asia/Tokyo, the actual next run must occur at that time in Asia/Tokyo.

For example:

• Requested time: July 11, 2026 at 11:00 JST
• Correct UTC time: July 11, 2026 at 02:00 UTC
• Correct epoch milliseconds: 1783735200000

At 10:18 JST, the UI should report that the next run is approximately 42 minutes away.

The following values must all agree:

• The time displayed in the Automations UI
• The countdown shown as Next run in ...
• The stored next_run_at
• The actual execution time
• The time zone specified in DTSTART

If a time zone is omitted, Codex should either:

1. Use the resolved local system time zone consistently, or
2. Require an explicit time zone and reject ambiguous schedules.

It should not recommend omitting DTSTART if doing so silently interprets the requested local hour as UTC.

The automation create and update responses should also return the resolved time zone and next_run_at, preferably as both an ISO 8601 timestamp and epoch milliseconds, so the caller can verify the schedule before reporting success.

Additional information

This does not appear to be project-specific. I encountered it while configuring automations for different projects, including a website project and an AutoDayTrader research automation.

The issue affects both one-time scheduling and recurring wall-clock schedules. Existing active automations may therefore appear correct in the UI while running at the wrong actual time.

A manual workaround is to convert the intended local time to UTC before saving the recurrence, or to use a relative-delay heartbeat for short one-time delays. Neither workaround is safe as a permanent solution:

• Manual UTC conversion could become nine hours wrong in the opposite direction after the scheduler is fixed.
• Relative delays do not preserve an exact wall-clock time.
• A saved TZID is not currently sufficient evidence that next_run_at was calculated correctly.

Codex should validate the actual delay between the current time and next_run_at after every automation create or update. If the requested time is 42 minutes away but the calculated delay is approximately ten hours, the automation should not remain active.

Please make the behavior capability-based rather than version-specific, so clients can stop applying workarounds automatically once the scheduler is fixed.

I will attach screenshots showing the contradictory UI:

• Daily at 11:00 AM
• Next run in 10 hours

<img width="1366" height="190" alt="Image" src="https://github.com/user-attachments/assets/c163d649-dd07-4886-923e-093bbdacf6db" />

I'm writing the answer to the question What steps can reproduce the bug? here, because the form does not accept anything except the feedback ID:

1. Set the macOS system time zone to Asia/Tokyo.

1. In Codex, create a one-time automation for a specific local time approximately one hour in the future. For example:

• Current time: July 11, 2026 at 10:18 JST
• Requested automation time: July 11, 2026 at 11:00 JST

1. Attempt to create it with a time-zone-aware start time:

DTSTART;TZID=Asia/Tokyo:20260711T110000

1. Observe that immediate creation may reject DTSTART and suggest omitting it.

1. Create the automation using only the requested hour and minute.

1. Open the Automations screen.

1. Observe that the card displays the requested wall-clock time, such as:

Daily at 11:00 AM

1. Compare the countdown with the current time. At 10:18 JST, the card displayed:

Next run in 10 hours

1. The correct countdown should be approximately 42 minutes.

1. If next_run_at is available, convert it to both UTC and Asia/Tokyo. It resolves to the requested hour in UTC instead of the requested hour in JST.

1. Updating the same automation with an explicit TZID=Asia/Tokyo start time may update the saved recurrence, but the next-run calculation can remain nine hours late.

Feedback ID: no-active-thread-019f4ec9-3e11-7b20-b1fc-e886f763c0ba