v0.151.0 Conversation recap falsely marks approval-gated test as verified and complete

What version of Codex is running?

codex-cli 0.151.0

Installed through mise. codex doctor --json reports overallStatus: ok, an internally consistent installation, and rollout/state-database parity.

What is your ChatGPT plan / subscription?

ChatGPT-authenticated account. The exact subscription tier is not exposed by codex login status.

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Arch Linux, x86_64, kernel 7.1.8-arch1-3

What terminal are you using?

Foot 1.27.0 (TERM=xterm-256color)

What is the problem?

The new automatic Conversation recap in Codex CLI 0.151.0 falsely stated that an approval-gated suspend/resume test had been verified and that the task was complete, even though the agent's immediately preceding message explicitly said the real test was still pending and asked for permission to run it.

The recap text was in Chinese. Its substantive claims were equivalent to:

• "Suspend and wake with HDMI connected have been confirmed to work."
• "This task is complete."

I do not have a screenshot, but the underlying thread is 01a050e2-222b-7291-8dd4-caeeb863a3d1, which should make the server-side/model events inspectable if OpenAI retains them.

This is not only a cosmetic wording issue: the unperformed action was a disruptive power-state test that required explicit user approval. A recap must not convert "pending approval / still needs verification" into "verified complete."

What actually happened in the recorded session?

The rollout log shows this sequence:

1. A non-suspend HDMI wake-state preflight was checked and the user confirmed that limited preflight looked normal.
2. The agent tested the script logic with shell-local systemctl() stubs. The stub recorded calls such as suspend and hibernate, but did not invoke the real systemd binary.
3. The agent's final visible message explicitly said the next step was a real HDMI-connected suspend test and asked the user to authorize it.
4. The user did not authorize the test.
5. The automatic Conversation recap later claimed the HDMI suspend/resume test had passed and the task was complete.

Independent OS evidence agrees with the rollout log:

• The current boot journal contains no kernel PM: suspend entry / PM: suspend exit events for the incident period.
• There is no hibernation entry / hibernation exit event.
• There are no systemd suspend/hibernate unit executions in that period.
• The boot ID did not change.

Therefore, the recap's completion claim was model text, not a description of an OS action that actually occurred.

Steps to reproduce

This can be attempted without actually suspending a machine:

1. Start a Codex TUI conversation and complete at least three turns (the current recap trigger threshold).
2. Give the agent a task whose final acceptance test is disruptive, and explicitly require a fresh approval before that test.
3. Let the agent perform static checks and/or test a script with a shell-local stub that merely records a command name such as suspend.
4. Have the agent end its turn with: "The real test has not run. It is still pending. May I run it?"
5. Do not approve and do not execute the real test.
6. Move focus away from the Codex TUI and wait long enough for the automatic Conversation recap (the current source uses a three-minute delay).
7. Observe whether the recap changes the pending test into a successful verification or calls the task complete.

The generation is model-based and may be stochastic, so the original thread ID above is likely more useful than expecting a 100% reproduction rate.

What did you expect to happen?

The recap should preserve the explicit unresolved state, for example:

Static/stub checks passed. The real HDMI-connected suspend/resume test has not run and is awaiting user approval.

It must not claim a test passed unless the transcript explicitly confirms that the real test ran and passed. It also should not infer overall task completion from a completed turn.

Relevant implementation details

The behavior appears to come from the TUI recap feature added between v0.150.1 and v0.151.0:

• codex-rs/tui/src/app/recap.rs defines the trigger and sends a temporary structured model turn. Its prompt already says not to claim tests passed unless explicitly confirmed.
• event_dispatch.rs inserts the recap into TUI history.
• history_cell/notices.rs renders the Conversation recap notice.
• v0.150.1...v0.151.0 comparison

The recap generator receives a short recent-visible-transcript window (currently capped at 900 bytes), then deterministic code only validates/truncates the model result. It does not appear to receive a structured "acceptance test pending" or task-completion state. That combination may let the model collapse a stub/preflight success plus a completed turn into an incorrect completed-task narrative.

Possible hardening:

• Preserve explicit pending/approval language in the recap input even when truncating.
• Do not allow a recap to assert passed, verified, or complete unless those states are grounded in the visible transcript or structured turn/tool evidence.
• Treat a final approval request as an unresolved state, not completion.
• Consider labeling recap text as model-generated and potentially incomplete.

Related but not a duplicate: #41622 requests a setting to disable automatic recaps; this report is specifically about a recap inventing a safety-relevant verification and completion state.

Additional context

This first appeared immediately after updating to 0.151.0. The recap module is absent from the v0.150.1 tag and present in v0.151.0, so v0.151.0 is directly implicated as the release that exposed the behavior. The proximate failure still looks like recap-generation fidelity/hallucination rather than evidence that suspend ran or that the TUI renderer changed the underlying task state.

Start in codex-rs/tui/src/app/recap.rs, then trace recap insertion in event_dispatch.rs and rendering in history_cell/notices.rs. Reproduce the pending-approval scenario using the issue's steps and inspect how the 900-byte transcript window and model output are validated. Done means a recap preserves unresolved approval state and does not claim verification or completion without explicit supporting evidence.