Where to Put Stop Conditions in Codex Automation¶
For / Key Points
For: Practitioners who want Codex to handle long-running work and PR creation without increasing review load or quality risk.
Key Points:
- Stop conditions should be placed before work, after diffs, before PR creation, after CI, and before human approval.
- Codex Cloud and Codex Local have different execution surfaces, so they need different operational stop rules.
- A stopped run should leave evidence that changes the next run, not just a quiet skip artifact.
Published: 2026-07-12
When Codex runs for a long time, failure does not always appear at the end. The dangerous case is when there is already a clear reason to stop, but the automation keeps moving toward a PR. The question is simple: where should Codex automation stop so it does not create more review work?
The answer is to place stop conditions at five points: before work starts, after diffs are created, before a PR is opened, after CI runs, and before human approval. OpenAI describes Codex local workflows as running on the user device, while cloud tasks run in OpenAI-managed environments. It also notes that workspace permissions can govern Codex Local and Codex Cloud separately.1
That means “Codex is allowed” is not the same as “Codex may continue.”
Split Stop Conditions into Five Layers¶
Stop conditions are not an emergency button after Codex fails. They are gates that decide whether work may move to the next stage.
For example, an article or code automation should stop before work begins if the candidate is duplicated, unsupported by sources, or high risk. After a diff exists, it should stop if files outside the intended scope changed. Before PR creation, it should stop if paired files, tests, or writer self-checks are missing.
After CI, it should stop if logs have not been read. Before review, it should keep merge, publishing, and exception approval with a human.
The layers look like this.
| Layer | What It Stops | Example |
|---|---|---|
| Before work | Invalid candidates | Duplicate topic, missing evidence, missing permission |
| Diff | Uncontrolled changes | Unexpected deletion, wrong directory, very large diff |
| Before PR | Missing handoff quality | Missing article pair, unrun tests, failed self-check |
| After CI | Machine validation failure | Required checks failed, logs not inspected |
| Before review | Decisions automation should not make | Merge, publish, exception approval |
In a morning automation run, the sequence is concrete.
- If the topic plan collides with an existing article, Codex should switch candidates before writing.
- If the diff expands beyond the intended directory, the run should stop before PR creation.
- If CI fails, the PR should not reach review until the failed log has been inspected.
Now the stop location itself becomes the next improvement target.
GitHub pull requests expose conversations, commits, diffs, and checks in one review surface. The Checks tab shows automated tests, builds, and other CI workflows that run when commits are pushed.2 If stop conditions map to that surface, Codex output becomes review evidence rather than an unstructured pile of changes.
Permissions Alone Are Not Enough¶
Permissions are necessary, but they are not sufficient.
The risk profile differs between Codex Cloud and Codex Local. For cloud tasks, connected services, repository access, and workspace permissions are natural stop conditions. For local workflows, the working directory, git root, local credentials, and uncommitted files matter more.
The same “Codex opens a PR” workflow needs different checks.
- Cloud: Check connected repositories, target branches, external services, and workspace permissions.
- Local: Check cwd, git root, dirty files, local secrets, and generated artifact locations.
- Shared: Never automate merge, publishing, credential requests, or replacement of human approval.
The point is not to grant broad access and review later. Permissions narrow the entry point. Stop conditions divide what happens after entry.
Use CI as a Stop Reason, Not Just a Result¶
CI should not only say red or green. In Codex operations, CI should classify why automation stopped.
GitHub status checks indicate whether commits meet repository conditions.3 Branch protection rules can enforce workflows such as required reviews or passing status checks before changes are merged.4 Together, they provide a machine gate before a Codex PR reaches human review.
Still, a failed CI run should not be thrown at a reviewer unchanged. The runbook needs at least four outcomes.
- Self-repair: Formatting, locale-suffixed links, or deterministic syntax cleanup.
- Investigate: Test failures, dependency changes, or behavior mismatches that require log review.
- Stop: Authentication, secrets, external permissions, or human-only decisions.
- Repair PR: Repeated stops that show the automation itself needs a fix.
Without that classification, Codex can stop at the same place every morning. If people only inspect active PRs, a skip artifact alone will not fix the process. A structural stop should become a maintenance PR, not another quiet skip.
What the PR Body Should Prove¶
A PR body is not a diary of what Codex tried. It is evidence that the stop conditions were passed.
Reviewers need to know what was selected, what was rejected, what checks ran, and where manual attention belongs. If that information is absent, the reviewer has to reconstruct the workflow from the diff.
At minimum, include these five items.
| Item | Purpose |
|---|---|
| Lane and target reader | Fix the experiment scope |
| Selected and rejected candidates | Make duplicate and evidence decisions reviewable |
| Checks executed | Show self-check, quality gate, and CI state |
| Manual review points | Narrow where humans should read |
| Next action on stop | Distinguish skip, repair, and maintenance PR |
A PR that passes stop conditions gives reviewers a reading order. A run that stops gives the next automation a reason to behave differently. That separation is the operational core of long-running Codex work.
The Boundary That Should Remain Human¶
Codex automation maturity is not measured by how far it can proceed automatically. It is measured by how early and how clearly it can stop.
The final boundary is the human merge decision. Codex can produce a candidate, run checks, and leave artifacts. But choosing which PR to adopt, which exception to allow, and which failure should change policy remains a human decision.
Automation increases speed. Stop conditions prevent speed from outrunning quality control. Before delegating work to Codex, define not only what it may do, but what must happen when it stops.