I would automate the second successful run, not the first exciting demo. Repeating a task changes the problem: now inputs go missing, schedules overlap and somebody has to notice when the output stops being useful.
The target is a boringly inspectable run. For the fictional campaign report, that means a dated input, a generated draft, reconciliation checks and an owner who can explain a failure.
Choose the recurring unit of work
A good automation has a bounded input and output. For Cedar Metrics, each run could read one dated campaign export and create a draft report with totals and missing-field notes. It should not have to decide which unlabelled file is probably the latest export.
Define a reporting window and output naming convention. If no new input exists, the task should report that condition rather than reuse an old file without explanation. The owner should be able to distinguish a quiet business period from a failed data handoff.
I would keep the first recurring task read-only with respect to external systems. Producing a draft is enough to establish whether the process earns attention. Sending or updating records adds additional failure modes that deserve their own design.
TipUse a dated source manifest so each run can state exactly which input it used.
Use desktop scheduling when it fits the environment
Supported desktop automations can run local tasks on a schedule. The local computer, app and required files must be available. That makes the approach suitable for work whose environment genuinely lives on that machine, provided the availability requirement matches the business need.
For repository tasks, worktree-based execution can isolate changes from the main working directory. Isolation makes it easier to inspect a result, but it does not decide whether the change is correct or whether it should be merged.
Create the task from the accepted manual instructions and inspect its saved schedule and environment. Review the first result before increasing cadence. A recurring job should begin with the same clarity as the manual run that proved it.
TipTest the scheduled environment, not only an interactive run from a different folder.
Use codex exec for software-owned invocation
codex exec runs a task without the interactive terminal interface. Your script, CI job or scheduler decides when it starts and how completion is handled. This is useful when the task belongs inside an existing operational workflow.
The default non-interactive sandbox is read-only. Current documentation recommends an explicit --sandbox workspace-write flag when the task needs project edits; --full-auto remains a deprecated compatibility flag. Choose permissions intentionally rather than inheriting an unexplained command from an old example.
Start with a read-only report or inspection. The command below requests a final summary without changing files. Once the output is useful, your surrounding program can capture it and handle the run’s status according to your own operating requirements.
TipA cron entry is only a trigger; you still own logs, failures, credentials and output delivery.
Capture output and completion separately
In ordinary codex exec use, progress is streamed to stderr and the final agent message goes to stdout. With --json, stdout becomes a JSON Lines event stream. These modes serve different consumers; do not parse an event stream as though it were a single final JSON object.
For a stable final data contract, the CLI supports --output-schema with a JSON Schema, and -o or --output-last-message can save the final message to a path. Choose a new output path or an intentional overwrite policy so a failed run does not quietly replace the only useful report.
Capture the process result and meaningful events as well as the final text. A persuasive paragraph should not hide a failed turn, unavailable source or incomplete check. The surrounding automation needs a clear success condition it can evaluate.
TipKeep diagnostic logs distinct from the artifact intended for a business reader.
Preserve deterministic checks outside the model
The fictional campaign fixture has known totals. A small ordinary program can sum the rows and verify aggregate CPL without asking a language model to judge its own arithmetic. Use that check as part of the automation’s acceptance condition.
Codex can help create and maintain the program, but the recurring check should remain explicit. When an input changes, validate its required fields, period and units before interpreting the business result. A schema can catch a missing field; metric checks can catch a wrong denominator.
I would keep the recommendation separate from those checks. “The totals reconcile” is a verifiable state. “We should change campaign spend” is a judgment that requires additional evidence and review. The automation should not blur them into a single success label.
TipUse a known fixture in CI and a source-reconciliation check on each real export.
Design for overlap and partial failure
Two scheduled runs can overlap if one takes longer than expected. If both write the same file or update the same record, the result can become ambiguous. Use the surrounding scheduler’s concurrency controls or a clear lock and output strategy appropriate to the system.
Partial failure matters for external actions. A request may succeed in the target service even if the caller loses the response. Retrying without checking can create duplicate notes or messages. Use stable run identifiers and application-level duplicate prevention for workflows that perform such writes.
For a first report automation, keep outputs dated and preserve previous successful artifacts. If the current run fails, report the failure rather than presenting yesterday’s report as fresh. That simple distinction prevents an operational issue from becoming a false business statement.
TipDefine what happens when the next scheduled run arrives before the previous one finishes.
Operate credentials, usage and ownership
A non-interactive environment needs a supported authentication setup available to the process. Saved CLI authentication and CI credential patterns have different operational implications. Follow the current official authentication guidance and keep secrets outside source files and logs.
Monitor usage against the value of the task. A narrow weekly repository summary and an open-ended daily investigation can have very different costs and durations. Keep the scope and model choice tied to the required result, then inspect the first runs before scaling frequency.
Assign an owner who can update the instructions, repair access and pause the schedule. An automation without an owner tends to outlive the assumptions that made it useful. The job may be unattended, but its maintenance is still somebody’s work.
TipRecord the task owner and the conditions that should pause the schedule.
Where Codex automation goes wrong
The recurring mistakes are scheduling an untested prompt, relying on an unavailable local environment and treating any final text as success. Another is assuming worktree isolation proves business correctness. It only gives the changes a separate place to live.
Keep the first version small enough to inspect after every run. Once it behaves predictably, add one capability at a time and test its failure path. A new source, external write or output consumer changes the operating contract.
A useful automation should reduce repeated effort while preserving visibility into the result. If nobody can tell which inputs produced the report, slow down and repair that link. Which manual check must remain visible when your workflow starts running without you?
How to set it up
Prove the manual procedure
Use the fictional fixture and define the exact output and reconciliation checks.
Choose the trigger
Use a supported desktop schedule or an external scheduler that invokes codex exec.
Set the operating contract
Define environment, permissions, authentication, output paths, completion checks and failure reporting.
Inspect early runs
Compare results with the reference, test missing inputs and overlapping runs, then adjust cadence and scope.
Frequently asked questions
Is codex exec a scheduler?
No. It runs a non-interactive task. Your scheduler or CI system decides when to invoke it.
What are its default permissions?
The current documentation says codex exec defaults to a read-only sandbox.
How do I permit workspace edits?
Use the documented explicit --sandbox workspace-write option when the task and environment require it.
Should I use --full-auto in new scripts?
No. Current documentation marks it deprecated and recommends explicit sandbox configuration.
What does --json return?
A JSON Lines event stream, not merely one final response object.
Can I request a final schema?
Yes, the CLI supports --output-schema for the final response. Validate business meaning separately.
Do worktrees approve changes automatically?
No. They isolate repository work; the result still needs appropriate review and verification.
Must a local scheduled task’s computer be available?
Yes. Local desktop automation depends on the app, machine and required files being available.
Sources & further reading
ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.
Related GTM workflows
Use these existing playbooks to explore the business workflow. Adapt their tool-specific steps to your chosen environment and check the result.