Codex Scheduled Tasks Running at Wrong Times? Audit the Schedule

If a Codex scheduled task shows a next run that is not present in its recurrence rules, pause the task before changing the rules. Preserve the configured schedule and recent run history, verify the computer's timezone, expand the allowed times independently, and compare both the displayed countdown and actual executions against that list.

Do not keep a billable task enabled while you investigate. A wrong countdown can be a display defect; an off-schedule execution is a different and more consequential failure.

The Short Answer

Use this decision table:

OpenAI Codex issue #37973, opened August 11, 2026, documents the exact distinction. A Windows user configured two weekday rules whose intended times included 13:00 and 14:30. At about 13:22 in Asia/Baku, Codex showed the next run in 40 minutes, approximately 14:02, and the task later ran at times outside the rules. The report also says the UI fell back to Custom schedule....

That is one current report, not proof that every Codex automation is affected. Its value is the reproducible signature: an actual or displayed minute that no configured rule can produce.

Preserve the Evidence Before Editing

Capture these items while the original task still exists:

• Codex app version and operating system;

• the complete recurrence rules;

• the task's configured timezone, if shown;

• the computer's current local time and timezone;

• the displayed next-run countdown;

• the resulting local next-run time;

• recent actual run timestamps; and

• whether those runs consumed usage or triggered an external Action.

Then pause or disable the task in Codex. Do not delete it. Deletion removes the easiest way to compare the original configuration with the failure.

On Windows, capture the local clock and timezone in PowerShell:

Get-Date -Format o
Get-TimeZone | Select-Object Id, DisplayName, BaseUtcOffset
tzutil /g

Expected result: the clock includes its UTC offset, and both timezone commands identify the zone you intended. If Windows reports another zone, fix that boundary before testing Codex again.

Expand the RRULEs Independently

An iCalendar recurrence rule combines each value in BYHOUR with each value in BYMINUTE for every allowed BYDAY. RFC 5545 defines those recurrence parts. You do not need to infer the next slot from the Codex countdown.

For example:

RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8,11,14,17,20;BYMINUTE=30
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=10,13,16,19,22;BYMINUTE=0

The allowed weekday times are:

08:30  10:00  11:30  13:00  14:30
16:00  17:30  19:00  20:30  22:00

The minute 02 appears in neither rule. A displayed 14:02 or an actual run at 14:02 is therefore off-grid regardless of the scheduler's internal cause.

For a different pair of rules, use this dependency-free PowerShell check:

$rules = @(
  'RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8,11,14,17,20;BYMINUTE=30',
  'RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=10,13,16,19,22;BYMINUTE=0'
)

$times = foreach ($rule in $rules) {
  $parts = @{}
  ($rule -replace '^RRULE:', '') -split ';' | ForEach-Object {
    $key, $value = $_ -split '=', 2
    $parts[$key] = $value
  }

  foreach ($hour in $parts.BYHOUR -split ',') {
    foreach ($minute in $parts.BYMINUTE -split ',') {
      '{0:D2}:{1:D2}' -f [int]$hour, [int]$minute
    }
  }
}

$times | Sort-Object -Unique

Expected result: a sorted list containing only the allowed local times. This check validates the explicit hour-minute combinations. It does not reimplement timezones, daylight-saving transitions, exclusions, or the rest of RFC 5545.

Compare the Display and the Run History

Convert the countdown into a local time while the evidence is fresh:

observed local time + displayed countdown = displayed next run

Then compare the result with the independently expanded list.

Record three states separately:

1. Configured: what the recurrence rules permit.

2. Displayed: what Codex says will happen next.

3. Executed: what the run history proves happened.

Do not collapse them into “the schedule is broken.” A mismatch between configured and displayed state is sufficient to pause. A mismatch between configured and executed state is stronger escalation evidence.

Use a Bounded Canary

After preserving the original evidence, test a separate harmless task with one weekday, one hour, and one minute. Schedule it far enough ahead that the app can save and display the next run before the slot arrives.

The canary should:

• read only local, non-sensitive state;

• finish in under a minute;

• avoid external writes;

• avoid paid provider calls; and

• produce a timestamped completion receipt.

Do not turn the production task back on to see whether it fails again. A canary separates scheduler behavior from the Action's cost and side effects.

Preflight the External Action Separately

If the scheduled task calls GitHub, PostHog, Google Search Console, or another service, verify that capability outside the scheduler. This prevents a valid Action failure from being misread as a timing failure.

Install or update Aident Loadout from the canonical setup guide:

Follow https://aident.ai/SETUP.md

Confirm account and Vault state:

aident account auth status
aident vault vault --action status

Discover the current read Action in staging, inspect its schema, and preflight the exact harmless input:

aident capabilities search \
  --query "read the small external result needed by this scheduled task" \
  --targetEnv staging

aident capabilities get --name "<exact Action name>"

aident capabilities preflight \
  --name "<exact Action name>" \
  --input '<reviewed read-only input>'

Preflight validates the current contract and credit boundary without dispatching the provider. Do not execute the Action merely to debug a wrong schedule. First prove that the scheduler produces an allowed slot.

If the task can spend repeatedly, add the AI agent cost guardrails before re-enabling it. After the canary, use the Action usage audit workflow to reconcile what actually ran rather than trusting the next-run label.

What Not to Do

• Do not delete the original task before recording its rules and history.

• Do not edit the system clock to force a reproduction.

• Do not assume a Custom schedule... label is itself the bug.

• Do not repeatedly run a billable or write-capable task as a canary.

• Do not convert the rules to UTC unless the product contract explicitly requires UTC.

• Do not claim a timezone cause when the timezone is correct and an off-grid minute remains.

• Do not call providers directly when the scheduled workflow is supposed to use a governed integration boundary.

A Safe Prompt for Codex

Audit this scheduled task without editing, deleting, enabling, or running it.

Capture the Codex app version, operating system, complete recurrence rules,
configured timezone if visible, current local time and UTC offset, displayed
next-run countdown, calculated local next-run time, and recent actual run times.

Expand only the explicit BYDAY, BYHOUR, and BYMINUTE combinations independently.
Show the allowed local times, then classify configured, displayed, and executed
state separately. If any displayed or actual time is off-grid, recommend that I
pause the task and produce a sanitized escalation receipt. Do not speculate
about root cause.

If the task uses an external service, use the installed public aident CLI to
confirm account and Vault status, discover the current read Action in staging,
inspect its schema, and preflight one reviewed harmless input. Do not execute
the provider Action and do not bypass Aident 

Success is not “the countdown looks close.” Success is a receipt proving that the saved rule, the displayed next run, and the actual execution agree on an allowed local time.

Escalation Receipt

Include:

• app version and platform;

• timezone name and UTC offset;

• sanitized recurrence rules;

• observation timestamp;

• displayed countdown and calculated next-run time;

• the allowed time list;

• actual off-grid run timestamps;

• whether the task was paused;

• whether usage or an external side effect occurred; and

• canary result, if a separate canary was safe to run.

Keep prompts, credentials, repository contents, and provider payloads out of the report.

Verify One Scheduled Action Safely

Follow https://aident.ai/SETUP.md

Set up Aident Loadout and preflight one scheduled Action

Sources

• OpenAI Codex issue 37973: scheduled tasks execute at incorrect times, opened August 11, 2026 and reviewed August 12, 2026.

• RFC 5545: iCalendar recurrence rules, reviewed August 12, 2026.

• Live Aident Loadout catalog, schemas, and preflights, inspected August 12, 2026.

Refresh this guide when OpenAI confirms the cause or fix, Codex changes its schedule editor or run history, or the public Aident CLI changes its discovery and preflight contract.