How to debug a missing Codex Automation PR¶

For / Key Points

For: Developers who use Codex Automation for scheduled research, fixes, or PR creation, but need a clear order for debugging when the expected pull request does not appear.

Key points:

A missing PR can mean no run, a mid-run stop, or a post-PR failure.
Start with the schedule and run history, not CI.
Separate workspace, permissions, PR state, and human review so ownership stays clear.

Published: 2026-06-27

When a scheduled pull request does not appear in the morning, opening the CI page first is usually a detour. CI runs after a PR exists. If the automation never started, there may be no CI log to inspect.

This article answers one operational question: when Codex Automation misses an expected PR, what should you check first? OpenAI describes Codex Automations as a way to run background work on a schedule.¹ That means the first diagnostic question is not whether the generated content is good, but whether the scheduled run started at all.

Split the symptom into three states¶

"No PR" is not one failure mode. At minimum, it can mean no run, a mid-run stop, or a failure after the PR was created.

State	What happened	First place to check
No run	The automation did not start after the scheduled time	Schedule, run history, time zone
Mid-run stop	The automation started but did not reach PR creation	Run log, workspace, permissions, artifacts
Post-PR failure	A PR exists but CI or review blocks progress	PR state, CI log, review policy

This split changes the next action. If there is no PR, inspect the layers before CI. If a PR exists, then CI and review status become relevant.

Scenario: a five-minute check when no PR appears¶

Suppose an automation is expected to open a PR every morning at 9:00, but nothing appears by 9:05. The question is not "why did the article fail?"

This is the reframe. The better question is which state transition did not happen?

For a five-minute check, this order is enough.

If no new run exists, inspect the schedule and time zone.
If a run exists but no PR exists, inspect logs, workspace, and permissions.
If a draft PR exists, inspect unfinished automated checks or editing conditions.
If a ready PR exists, inspect human review and CI.

Fixing this scenario first keeps the investigation pointed at the right layer. The CI page matters after you know a PR exists.

Check the schedule and run history first¶

The first question is whether the automation started at the expected time. Check the schedule, time zone, recurrence, and latest run timestamp together.

For a daily "open a PR every morning" task, use this order.

Is the schedule enabled?
Does the scheduled time match the intended time zone?
Did a new run appear after the expected time?
If the run failed, which stage produced the error?

If there is no run history for the expected time, editing the article body or PR template will not help. The failure is upstream of content generation.

Confirm the workspace and target repository¶

If a run exists but no PR appears, inspect where the automation worked. OpenAI notes that, in Git repositories, automations can run in a local project or a worktree.¹ OpenAI's worktree documentation describes a worktree as a separate checkout of the same repository.²

That detail matters in practice. An automation can do real work, but the result can still be invisible if it ran in the wrong checkout, branch, or repository.

Check these points.

Is the target repository correct?
Is the target branch or worktree the one you expected?
Does the automation have permission to create commits, push branches, and open PRs?
Did generated files only land in ignored or temporary paths?
Did commit, push, or PR creation fail partway through?

This is not a question of model quality. It is a Git and execution-context question.

Do not inspect CI before a PR exists¶

CI is downstream. If no PR exists, CI is rarely the root cause.

Use a simple order. No run means inspect the schedule. A run with no PR means inspect logs, permissions, workspace, and artifacts. A PR means inspect CI and review state.

Reversing that order sends you toward the most visible screen, not the earliest failure. Even when CI is red, the code may not be the cause. A CI job can fail before steps run because of provider limits, billing, permissions, or workflow configuration.

Separate human review from automation failure¶

If a PR exists, the system did not do nothing. The next question is whether the PR is waiting for a person or waiting for an automated check.

Some teams intentionally create draft PRs first, then mark them ready after automated checks pass. That is a reasonable policy, but the state needs an owner. A PR body or dashboard should say who acts next.

PR state	How to read it	Next action
No PR	The automation did not start or stopped before PR creation	Inspect run history and logs
Draft PR	Candidate output is still under automated checks or editing	Inspect unfinished conditions
Ready PR	A human can review it	Inspect diff, evidence, and CI state
Failed CI	A downstream check stopped the PR	Separate code failure from environment failure

The important step is adding a subject to the state. Did the automation stop it? Did CI stop it? Is a human now expected to decide?

Once that is explicit, people stop waiting on the wrong thing.

Keep the daily health check small¶

The routine check should not become a long investigation. Five fields are enough for most missing-PR cases.

Order	Check	What it tells you
1	Schedule	Whether the expected time and time zone are correct
2	Run history	Whether the automation started
3	Workspace	Whether it used the expected repository, branch, or worktree
4	Permissions and artifacts	Whether it reached commit, push, and PR creation
5	PR and CI	Whether the remaining work is human review or downstream failure

This checklist is not tied to one blog, repository, or private workflow. Any scheduled coding-agent workflow that creates pull requests can use the same order.

Summary¶

When Codex Automation does not open the expected PR, first classify the state. Is it no run, a mid-run stop, or a post-PR failure?

Then check schedule, run history, workspace, permissions, PR state, and CI in that order. That sequence keeps human review separate from automation failure. Trustworthy automation is not only about producing output; it must also explain where it stopped.

OpenAI Developers, Automations - Codex app. ↩↩
OpenAI Developers, Worktrees - Codex app. ↩