›_ Codex Issues
Codex Issues / #32067

One-time local automation stayed ACTIVE but did not run at scheduled time

Open 💬 3 comments Opened Jul 10, 2026 by pandigita
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

A one-time Codex Desktop automation was created successfully and shown as ACTIVE, but it appears not to have fired at the scheduled local time. This caused a time-sensitive user task to be missed.

Details

  • Automation id: activate-claude-usage-window
  • Kind: cron
  • Destination/execution environment: local
  • Schedule stored in automation file:
  • RRULE:FREQ=DAILY;COUNT=1;BYHOUR=11;BYMINUTE=20;BYSECOND=0
  • Intended time: 2026-07-10 11:20 local system time
  • Local timezone: Asia/Ho_Chi_Minh
  • Current time when checked: 2026-07-10 ~14:17 local time
  • Automation status before cleanup: ACTIVE

The automation was created through the Codex app automation tool. The original attempt to include an explicit DTSTART;TZID=Asia/Ho_Chi_Minh:20260710T112000 was rejected, so it was recreated using the local wall-clock RRULE above.

Expected behavior

At 11:20 local time, Codex should create/run the one-time local automation task, execute the prompt once, and leave a run/thread/log record indicating success or failure.

Actual behavior

After 11:20 had passed, I found no evidence that the automation ran:

  • No standalone Codex thread/task was created around 11:20.
  • No relevant Codex log entries appeared around 11:20.
  • The external side effect the task was supposed to perform did not occur.
  • The automation config still existed and still showed ACTIVE, despite COUNT=1 and the scheduled time being in the past.

The machine was intentionally kept awake, logged in, and active for the scheduled time window. The user confirmed the system did not sleep or log out.

Local evidence checked

The local automation config existed at:

~/.codex/automations/activate-claude-usage-window/automation.toml

I checked:

  • ~/.codex/state_5.sqlite for threads created around 2026-07-10 11:00-12:30.
  • ~/.codex/logs_2.sqlite for automation/task/Claude-related logs around that same window.
  • The external target app history, which showed only the earlier manual setup test and no 11:20-era run.

Impact

This was a time-sensitive one-time automation the user relied on while asleep. The UI state made it look scheduled and active, but the task did not execute or at least left no observable run/failure record.

Requested improvement

Please add one or more of:

  • A reliable run record for every due automation attempt, including skipped/failed attempts.
  • Clear UI status when a one-time automation is overdue, missed, or unable to run.
  • A validation warning when an RRULE without DTSTART may not be anchored to the expected local date/time.
  • A way to test-fire or dry-run the automation scheduler path immediately after creation.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30705

Powered by Codex Action

pandigita · 1 month ago

Additional reproduction: I created a simpler one-time local cron automation at 2026-07-10 15:52:56 +07 for 15:55 local time, with no external side effects and only the expected response text AUTOMATION_SMOKE_TEST_FIRED 2026-07-10 15:55 Asia/Ho_Chi_Minh. At 15:56:17 and again at 15:58:40 local time, there was still no new Codex thread, no matching log entry in ~/.codex/logs_2.sqlite, and the automation config still showed status = "ACTIVE" with RRULE:FREQ=DAILY;COUNT=1;BYHOUR=15;BYMINUTE=55;BYSECOND=0. This reproduces the scheduler-not-firing behavior with a minimal Codex-only task while the app/session was active.

WRw5w · 1 month ago

I can reproduce the same failure family on Windows 11.

Environment:

  • Codex Desktop: 26.707.3748
  • codex-cli: 0.144.1
  • Windows 11 build 26200
  • App and machine remained running

An app-native one-shot heartbeat was created successfully for 09:30
Asia/Shanghai. The definition could be viewed afterward and remained ACTIVE,
but by 11:05 no continuation turn or observable run/failure record had been
delivered.

This highlights an important distinction: successful create/view and ACTIVE
status prove persistence of the automation definition, but do not prove that
the due occurrence was admitted, claimed, or dispatched by the scheduler.

Could Codex expose an immutable occurrence/run ID and observable stages such as:

persisted -> armed/due -> claimed -> prompt_enqueued -> turn_started -> completed

with explicit failed, skipped, expired, and misfired states, attempt timestamps,
failure reasons, and an idempotency key for at-least-once retry?

The closed automation stack in #28612, #28617, and #28618 already sketches
claims/leases, a durable worker loop, cold-resume/busy-thread deferral, and
completion only after prompt submission. Those semantics, plus a test-fire
health check using the same dispatch path, would make scheduled work much safer
to rely on.