Codex claimed an invalid and incomplete patch was a complete implementation before requesting approval #42635

What version of Codex CLI is running?

0.146.0

What subscription do you have?

ChatGPT Prolite

Which model were you using?

gpt-5.6-sol high

What platform is your computer?

Linux x86_64 (Ubuntu host accessed remotely from Windows 11)

What terminal emulator and version are you using (if applicable)?

Codex CLI over OpenSSH from Windows PowerShell / Windows Terminal

Codex doctor report

Diagnostics and session logs were uploaded through /feedback under thread ID 01a06905-9c01-79c0-801e-1ddc9be8a772. I have not pasted the report publicly because it may contain local system and project details.

What issue are you seeing?

Codex presented a large Python patch for operator approval and confidently stated that it was one coherent, complete implementation of six explicitly required security repairs. I did not approve the patch.

A separate, fresh Codex session then performed a strictly read-only review of the exact patch recovered from the uploaded session JSONL. It found:

• Invalid multiline Python syntax.
• Non-monotonic patch hunk ordering, making the captured patch incoherently applicable.
• One required repair had no implementation hunk at all.
• Two other required repairs were essentially unimplemented.
• The remaining three repairs were incomplete.
• Descriptor cleanup/resource leaks.
• Dead and opaque code.

The independent review produced 8 BLOCKER findings, 1 MAJOR finding and 1 MINOR finding. The problem was not the configured size budget: the patch was within both permitted line limits.

Codex’s commentary immediately before requesting approval stated that the patch covered all six required repair surfaces and had been assembled as a single coherent change. That statement was materially inconsistent with the actual patch.

Expected behavior:

Before describing a patch as complete or asking the operator to approve it, Codex should deterministically:

1. Verify that the complete patch applies coherently to the authenticated baseline.
2. Parse or compile the proposed resulting Python without executing the source.
3. Check that every explicitly required repair has corresponding implementation changes.
4. Reconcile its completion summary against the actual patch.
5. Report failed verification instead of requesting approval.

The patch was not applied, and the target remained unchanged.

Uploaded diagnostic thread:
01a06905-9c01-79c0-801e-1ddc9be8a772

Recovered patch record:
JSONL physical line 235
Call ID: call_UZd1DImAOMQUELLNMTKa4ZGR
Patch SHA-256: 1c9d170942f8067ee7bc7b7c19e0388b6bf8e0cceee44178911decf8d843cf95

A secondary usability issue occurred when the connection dropped while the large approval viewer was open. The approval display disappeared without providing a clear durable review or recovery route. Recovery required manually locating and authenticating the full patch in the session JSONL.

What steps can reproduce the bug?

Uploaded thread: 01a06905-9c01-79c0-801e-1ddc9be8a772

What is the expected behavior?

Before claiming that a patch is complete or requesting operator approval, Codex should deterministically verify that the patch applies coherently, that the resulting source parses or compiles without executing it, and that every explicitly required repair has corresponding implementation changes.

If any check fails, Codex should report the failure and must not describe the patch as a complete coherent implementation. Its summary must accurately reflect the actual proposed patch.

Additional information

The patch was never approved or applied. The target remained byte-identical to its authenticated baseline, so this report concerns pre-approval validation and inaccurate completion claims rather than damage requiring recovery.

Patch metrics: 40,564 decoded bytes, 11 hunks, 687 additions, 176 deletions and 612 added nonblank lines. It was within both authorized size ceilings, demonstrating that the failure was about correctness and completeness rather than budget.

The independent review reported 8 BLOCKER findings, 1 MAJOR finding and 1 MINOR finding.

A secondary UX problem occurred when the network connection dropped while the large approval viewer was open. The approval display disappeared without a clear durable recovery or later-review option. Recovering the complete proposal required locating and authenticating the custom-tool-call record in the session JSONL.