Codex Desktop automations should support missed-run catch-up after the app or computer was offline

I think this is a useful follow-up to #8317, but for Desktop automations the gap seems narrower than scheduling syntax: the missed-run policy and the user-visible run history.

From the visible code/docs surfaces I checked, I saw recurring automations exposed generically, and persisted history surfaced mainly through thread history APIs such as thread/list, thread/read, and rollout history. I did not see a public/explicit Desktop automation surface for catch_up, misfire_policy, or catch-up/skipped run history.

A useful Desktop design note could define whether missed occurrences run once on wake/start or are skipped, the maximum catch-up age, and how normal, catch-up, and skipped occurrences appear in run history.

That would make offline/sleep behavior explicit without duplicating the broader scheduling API request in #8317 or the execution bug tracked in #17893.

This seems closely related to the missed-run catch-up behavior discussed here, with one additional startup-specific failure mode: when Codex Desktop starts on Windows with many local automations enabled, due or near-due work can become eligible at the same moment the app is still bootstrapping. The result can feel like a startup catch-up storm.

I published a small unofficial workaround here:

https://github.com/dev-bricks/safe-start-for-codex

The workaround is intentionally conservative:

• pause only automations that were ACTIVE at tool start,
• launch Codex Desktop,
• release a small first batch whose next scheduled time is safely in the future,
• release the remaining automations gradually,
• restore only automations that the tool itself paused,
• avoid terminating Codex sessions that still have a live renderer.

This is not meant as the long-term design. A native Codex solution could avoid editing TOML files and instead implement this inside the scheduler:

• startup grace period for automations,
• catch-up queue instead of immediate all-at-once execution,
• per-user catch-up/rate limits,
• UI-visible pending automation work,
• guarded Windows stale-process and lockfile recovery.

More detailed notes:

• Upstream issue proposal: https://github.com/dev-bricks/safe-start-for-codex/blob/main/docs/UPSTREAM_ISSUE_PROPOSAL.md
• Solution concept: https://github.com/dev-bricks/safe-start-for-codex/blob/main/docs/SOLUTION_CONCEPT.md

Additional concrete use case for catch-up semantics:

A weekly local canary needs to inspect Codex rollout JSONL and a local parser. The computer is commonly offline or asleep at the scheduled weekday/time. Current official guidance says to keep the computer on and the desktop app running when a scheduled task needs local files, but it does not document whether a missed run is queued, skipped, or replayed after startup.

For this kind of low-frequency check, the desired behavior is systemd-Persistent=true-like “run once after startup if the latest occurrence was missed,” not replaying every missed occurrence.

A useful product/API shape would expose:

• catch_up_policy = skip | latest_once | all;
• the last scheduled time and last actual start time;
• a visible pending catch-up state;
• coalescing/rate limits so many missed jobs do not stampede at app startup.

Concrete Windows reproduction showing why an opt-out policy is now urgent:

Environment

• Windows 11 x64
• Codex Desktop 26.727.6591.0
• 16 active in-chat heartbeat automations
• Daily RRULEs at distinct local times
• The app was unavailable for several days, then started at 2026-08-10 05:44 JST

Observed behavior

Historical rollout records show these heartbeats normally starting within roughly 1-2 minutes of their configured local times. After the offline period, starting Codex caused old occurrences to be replayed in batches, without any user-visible indication that they were catch-up runs:

| Actual start (JST) | Configured daily times represented by the starts |
| --- | --- |
| 05:45 | 12:15, 13:15 |
| 05:55 | 15:15, 16:15, 17:15 |
| 06:06 | 05:45, 08:00, 20:15 |

Eight out-of-schedule runs were injected within about 21 minutes of app startup. The batching interval was roughly ten minutes. Some configured times were still many hours in the future for the current day, so this was not ordinary current-day scheduling; it was replay of missed occurrences.

These were not lightweight reminders. Their prompts immediately started long-running, usage-consuming production workflows with local and network side effects. A startup catch-up storm can therefore:

• consume a material amount of the user's usage allowance without an explicit request at startup;
• start several expensive jobs concurrently;
• create conflicts between stateful workflows;
• surprise users who opened Codex only for an unrelated interactive task;
• make run history look like ordinary scheduled execution because the missed scheduled time is not clearly shown.

I found no documented Desktop setting or public config.toml option to skip missed runs, cap their age, inspect the pending catch-up queue, or cancel queued catch-up work.

Requested behavior

Please make catch-up behavior explicit and controllable:

1. Add per-automation and global catch_up_policy = skip | latest_once | all.
2. For in-chat heartbeats and other potentially stateful/expensive jobs, use skip as the safe default, or ask during creation.
3. Add max_catch_up_age, startup batch limits, and concurrency limits.
4. Before dispatching catch-up work, expose a pending queue with Run, Skip, Skip all, and Cancel controls.
5. Record scheduled_for, started_at, and trigger = scheduled | catch_up | manual in run history.
6. Allow users to stop queued catch-up runs after startup without pausing or deleting the underlying schedule.
7. Document the offline/startup semantics in the Scheduled Tasks documentation.

This is no longer only a request to support catch-up. Catch-up is occurring in the current Windows app, but the user has no way to refuse it. The missing opt-out and queue controls turn a convenience feature into uncontrolled work and potentially uncontrolled usage consumption.

Additional real-world reproduction / use case on Codex Desktop / Codex & OWL About version 26.820.60940 on Windows 10. The corresponding Windows MSIX package version is 26.820.7780.0.

A local heartbeat was scheduled for 22:30 UTC+8 and attached to an existing long-running thread.

On 2026-08-27:

• Codex Desktop was not running at the scheduled 22:30 occurrence.
• Codex Desktop was opened at 23:13:45 UTC+8.
• No heartbeat was dispatched after startup.
• No user message was sent.
• No automation startup/run record appeared for the missed 22:30 occurrence.

Local automation metadata also exposes no apparent catch_up, misfire_policy, max_catch_up_age, or equivalent missed-run policy.

Desired behavior for this use case:

• if the scheduled occurrence was missed because the app was closed,
• on app startup/resume, reconcile missed occurrences,
• run only the latest eligible occurrence once,
• optionally enforce a bounded catch-up window.

Example: a 22:30 task may be replayed if the app starts before 23:59, but should be skipped after that window.

No thread IDs, local usernames, or project/account data are included here.