Codex CLI Scheduled Tasks: Options and Limits
Codex CLI does not schedule itself. You use the operating system scheduler or an external platform to run it on a timetable. Here is how each option works, what limits to expect, and how to track each run's outcome.
Updated 5 min read
Codex CLI has no built-in scheduler. It runs one task when you invoke it and exits. If you want it to run on a recurring schedule, such as a nightly review, a weekly report, or a regular code check, you use an external tool to invoke it at the right time.
The external scheduler is straightforward to set up, but it introduces a new problem: the outcome of each scheduled run needs to go somewhere reviewable. A tool like fenbs keeps each run's result and the next step outside the log file, so you can review what happened and decide whether the task needs attention without hunting through terminal output.
Option 1: OS schedulers (cron and Task Scheduler)
On macOS and Linux, cron is the standard way to run a command on a schedule. Add a crontab entry that calls a shell script wrapping your Codex CLI invocation. Run crontab -e to edit the schedule:
0 2 * * * /usr/local/bin/codex-nightly-review.sh >> /var/log/codex-review.log 2>&1
The script sets the working directory to the repository and calls Codex CLI with a fixed prompt and the --approval-mode full-auto flag, since no one is present to approve actions. Redirect output to a log file so you can review what happened.
On Windows, Task Scheduler does the same job. Create a basic task with a trigger set to your schedule and a program action pointing at a batch or PowerShell script. The Codex CLI on Windows guide covers environment setup that the scheduled task also needs.
Option 2: CI and automation platforms
If your project already has a CI pipeline, adding a scheduled workflow is often simpler than managing a cron job on a local or remote machine. GitHub Actions supports scheduled workflows with the schedule trigger, which accepts cron syntax. GitLab CI and other platforms have similar options.
The advantage is that the run happens on a controlled, clean environment and the log is stored with the pipeline history. The disadvantage is cost: each scheduled run uses CI minutes, and a long or token-heavy Codex CLI run can be expensive on a frequent schedule.
Consider whether ChatGPT's own scheduled task feature covers your use case before building a custom pipeline. It is a different product with different capabilities; see ChatGPT scheduled tasks for that comparison.
The approval mode problem in unattended runs
By default, Codex CLI pauses to ask for approval before taking actions. In a scheduled run, no one is present to approve, so the run stalls. You must set --approval-mode full-auto explicitly in scheduled invocations.
Full-auto means the agent acts without checking with you. For a scheduled code review that only reads files and writes a summary, this is low risk. For a scheduled task that commits or pushes changes, it is high risk. Scope the prompt narrowly and review the output before trusting the result in production.
Handling failures in a scheduled run
A scheduled Codex CLI run can fail silently. The cron job reports success because the shell script exited with code 0, but the agent produced an unhelpful result or made a change that needs reverting. Check the log file after each run rather than assuming silence means success.
For runs that make changes to the repository, add a validation step after the agent exits: run the test suite and check the exit code. If the tests fail, the shell script should exit with a non-zero code, which cron records in the system log and which a monitoring tool can alert on. A simple email notification when the script fails is often sufficient to catch problems before they compound.
What to do after each scheduled run
A log file tells you what the agent did. It does not tell you what to do about it. After a scheduled run, you need a place to record what was found, what was resolved, and what needs attention. Without that record, the results of each run accumulate without any action being taken.
A practical pattern is to end the Codex CLI invocation with a step that writes a short summary to a known location. That summary can be a file in the repository, a task comment, or a note in a project management tool.
Keep each scheduled run's outcome in one place
Create a recurring task in fenbs for each scheduled job. After each run, add a comment with what was found and what the next step is. Where we left off records the last reviewed state so you can see at a glance whether the last run produced anything that needs attention.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account and add a task for each recurring job you are running with Codex CLI.
- Write the task description with the goal, the schedule, and the criteria for a successful run.
- After each scheduled run, add a comment: what was found, what was changed, and what needs follow-up.
- Use Where we left off to record the last outcome and the next expected run date so you can see at a glance whether anything needs attention.
- If the scheduled run consistently finds nothing to do, record that as a Decision so the next person reviewing the schedule knows it is working correctly.
For managing longer automated runs that need to iterate until a condition is met, see Codex CLI loop patterns. For hooks that run before or after each agent turn, see Codex CLI hooks.