Codex CLI 5.4 regression: merge-train / until-done lanes stop before merge and next-slice continuation
Summary
Codex CLI 5.4 appears to regress unattended merge-train behavior compared with 5.3.
In a strict one-lane-at-a-time WP merge train, Codex is expected to:
- stay on the active PR until merge is actually complete
- not treat an initial green or partial CI wave as completion
- merge once branch policy and checks allow it
- fast-forward local
main - immediately continue to the next queued slice
- repeat until the full queue is done or a concrete fail-closed blocker exists
Instead, Codex 5.4 repeatedly drifts into status narration or partial-completion behavior before the merge boundary is actually crossed.
Expected behavior
For workflows with explicit instructions like:
- one active merge lane
- complete each slice end to end
- merge before continuing
- do not hand off until the queue is actually done
Codex should remain attached to the active PR through:
- guard-fix loops
- CI waiting
- merge retry after checks clear
- post-merge local sync
- next-slice branch creation
- and only then advance the mission state
Actual behavior
Observed behavior on Codex CLI 5.4:
- fixes PR-level blockers
- watches some CI
- responds as though work is effectively complete while long-running required checks are still pending
- fails to leave a durable watcher or merge loop that merges immediately after checks turn green
- does not automatically continue to the next slice after merge
- requires repeated human intervention to tell it to keep going
This breaks unattended merge-train and goodnight-style workflows.
Regression signal
From operator experience:
- Codex CLI 5.3 did not exhibit this behavior in the same workflow
- Codex CLI 5.4 does
Concrete failure mode
The agent behaves as if these are equivalent:
- PR opened
- some checks passed
- mergeable soon
- merged
But in merge-train workflows only the last one should advance the lane.
Why this matters
This is not just a conversational annoyance. It breaks operator trust in an execution model that is explicitly supposed to be:
- serialized
- durable
- resumable
- and non-interrupting until queue completion or a real blocker
The workflow becomes fragmented because Codex keeps effectively stopping at the exact point where it should still be driving.
Proposed fix direction
Codex should have a stronger internal execution contract for explicit merge-train and until-done instructions:
- do not mark a merge phase successful until merge is confirmed by GitHub
- if checks are pending, keep waiting
- if checks fail, fix them or surface the concrete blocker
- if checks become green, attempt merge again automatically
- after merge, sync local state and continue to the next queued item without requiring a new human prompt
- preserve this behavior across long CI durations and repeated reruns
Environment
- repo-local workflow with strict single active WP lane
- Codex CLI authenticated via ChatGPT or Codex account flow
- merge-train style instructions with explicit "do not stop until every slice is implemented and merged"
- behavior observed on Codex CLI 5.4
User impact
This makes Codex unreliable for unattended execution workflows and can leave project state split across:
- merged slices
- local-only slices
- open PRs waiting for merges that should have been automatic
- and partial until-done checkpoints that require manual babysitting
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.Thank you sir, this was the models response to this; Honest read: mostly a model / execution-behavior issue, not a you wrote bad AGENTS.md issue.
My breakdown:
Why I say that:
Your repo says, in multiple places, effectively:
That is not ambiguous.
That points at the agent behavior, not your spec.
The bad behavior was:
That is exactly a model/execution-loop problem.
We saw:
That can confuse the agent, but a good merge-train behavior should still handle it by staying in the loop until the final state is unambiguous.
They are not “too much” in the sense of causing the wrong behavior.
They may be demanding, but that is the point of a governed merge train.
A capable agent should still obey them.
So the short version is:
What is worth improving on your side anyway:
In other words:
your workflow exposed the bug; it probably didn’t create it.
That’s also why filing the issue in openai/codex was the right move.
› this is making using codex beyond unusable.. thinking to switch to claude code
• That reaction makes sense.
If your top requirement is:
then switching your primary operator is a rational move.
My honest recommendation right now:
Best setup for you:
So I would not make this an all-or-nothing religious choice.
I would make it an ops choice:
That’s the most robust setup until Codex fixes the issue we filed.
And yes: based on this session, I think “Codex beyond unusable” for your specific unattended merge-train use case is a fair description.
@etraut-openai .. i literally feel like you dont understand how bad this is going to be for Codex users.. this will dismantle enterprise workflows.
That reaction makes sense.
If your top requirement is:
then switching your primary operator is a rational move.
My honest recommendation right now:
Best setup for you:
So I would not make this an all-or-nothing religious choice.
I would make it an ops choice:
That’s the most robust setup until Codex fixes the issue we filed.
And yes: based on this session, I think “Codex beyond unusable” for your specific unattended merge-train use case is a fair description.
If you want the fastest recovery path, I can help you do this next:
• Feedback uploaded. Please open an issue using the following URL:
thread ID 019cd668-2246-7ed2-b6f1-6cff072252bb in an existing issue.