Codex Daily Workflow and Controls Part 02 | Scheduled Tasks, Cron, and What the Agent Still Has to Decide

A daily CI triage job is easy to schedule. Cron can start a command every morning, and that command can be a script which eventually invokes Codex.[3]

The harder part starts after the trigger. Codex still needs enough instruction to do the job, somewhere safe to run it, permission to make the intended changes, and a result that can be reviewed afterwards. Scheduled Tasks keep more of those decisions with the recurring job itself.[1][2]

Scheduled agent job anatomy showing that scheduling is only the trigger and a Codex Scheduled Task still needs an agent job contract around it

Figure 1 | Scheduling starts the job, but it does not define the whole agent contract.

What happens after the clock fires

A crontab entry can stay tiny: at this time, run this command. Cron does not need to understand the work inside that command.[3]

A Codex Scheduled Task carries more of the job definition. The instructions, execution environment, authority boundary and review path can stay attached to the task, while model and reasoning settings can be fixed when the workload actually needs that.[1][2]

None of this makes cron obsolete. A team can build the same chain with cron, a shell script, Codex CLI, Git worktrees, logs and notifications. Built-in scheduling simply keeps more of that glue inside the Codex workflow instead of asking you to assemble it elsewhere.

Model and reasoning settings sit in the same job definition, but there is little benefit in pinning them before the workload has shown a reason. A fixed extraction or classification task usually needs less reasoning than one which traces a root cause, edits several files and makes a final judgement. Frequency compounds the choice as well. A setting that is unremarkable once a day can become expensive when the same job wakes every hour.

Start with the default. If the task later develops a repeatable quality, latency or usage problem, pinning the model or reasoning level gives that setting a specific job to solve.[2]

Keep background writes away from unfinished work

If the job only reads logs, scans issues or summarises the repository, Local execution is often the simplest choice. It sees the checkout you are already using and avoids another integration step.

If the job writes code, Local needs more care. You may still be halfway through a feature when the scheduled job wakes up and edits the same checkout. Neither side has to do anything wrong for the working tree to become awkward. Codex supports Local and Worktree execution so background changes can be isolated from unfinished local work.[2]

Local is still reasonable when the edit is tightly bounded and you know exactly what the job will touch. If it can change several files, run for a while, or overlap with your own work in the repository, a separate worktree is easier to contain. The trade-off is extra setup: uncommitted local state does not simply appear there, the environment may need to be prepared again, and the resulting changes still need review and integration.

Scheduled runs also remain subject to sandbox and approval controls. OpenAI has fixed scheduled automations to honour the selected approval mode.[2] If an unattended job reaches an approval boundary while nobody is there, it waits.

Keep the write scope narrow enough that the job can finish on its own. Destructive, external or privilege-expanding actions can stay behind explicit review instead of giving every background run broader authority.

Reuse a Thread only when the work is still the same work

A fresh run is enough for a daily CI summary. The prompt and current data define the task, and yesterday’s conversation usually adds little.

A deployment which is still running is different. You may want Codex to come back in two hours, look at the same work and continue from the context already in the Thread. Thread automations support that pattern by waking the same Thread on a schedule.[2]

The trigger still matters. Waking every fifteen minutes to check deployment state is scheduled polling. Receiving an event when the deployment changes state is event-driven. Both can lead to agent work, but they differ in latency, idle runs and failure modes. Adding an agent after the poll does not turn the poll into an event trigger.[1]

Leave orchestration where it already works

If GitHub Actions, Jenkins, Airflow or an internal scheduler already owns triggers, retries, secrets, audit and alerts, moving only the timer into Codex may create a second control point without buying much.

OpenAI has also supported access-token flows for trusted non-interactive Codex local work launched from scripts, schedulers and private CI runners in ChatGPT Enterprise workspaces.[2] The existing orchestration can therefore keep its job, while Codex handles the agent work that follows.

Built-in Scheduled Tasks make more sense when the recurring job belongs to a personal or desktop workflow and you want the run to return to Codex for review. Pipeline-driven work usually fits better where the pipeline already lives.

`ACTIVE` is configuration state, not completion evidence

Seeing ACTIVE in the UI does not tell you how far the job will get.

The official Codex repository has reports of an automation staying ACTIVE without creating a Thread or visible run.[4] Another report got one step further: the scheduler created a Thread, but the configured prompt never became a user Turn and no model sampling followed.[5]

Those issues do not provide a product-wide reliability rate. They are useful because they expose different failure layers.

Automation verification ladder showing the proof path from configured state through scheduler firing, run creation, prompt dispatch, execution, output and review

Figure 2 | Verify the deepest layer your claim depends on.

Automation configured / ACTIVE
        ↓
Scheduler actually fires
        ↓
Run or Thread starts
        ↓
Prompt reaches an Agent Turn
        ↓
Model and tools execute
        ↓
Expected artifact or side effect appears
        ↓
Result passes review

Checking the first line leaves everything below it unproven.

Timing deserves the same check. The official repository also contains a report of local time and UTC handling disagreeing around an RRULE schedule.[6] That establishes a possible timezone/recurrence failure layer, not its frequency.

For the first scheduled run, choose something low-risk with an obvious result. Run the prompt interactively first, then schedule it soon enough that you can inspect one or two real executions. Check the firing time, Thread or run creation, agent activity, expected output and review path before moving to the intended cadence.

Only after the whole path has completed under observation should you move it to the intended cadence and stop watching every run.

References