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:

1. stay on the active PR until merge is actually complete
2. not treat an initial green or partial CI wave as completion
3. merge once branch policy and checks allow it
4. fast-forward local main
5. immediately continue to the next queued slice
6. 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