Windows Codex App: rejected apply_patch can leave a partial file modification after auto-review 400

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.72359

What subscription do you have?

ChatGPT signed-in account (the plan was not exposed in the available local diagnostics)

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

On Windows Codex Desktop, the built-in apply_patch operation was reported as rejected because the automatic approval reviewer failed with an internal model-routing error:

This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed: {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "unsupported_value",
    "message": "This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.",
    "param": "model"
  },
  "status": 400
}

However, the target file was still partially modified.

The session record contains three patch_apply_end events. All three have:

success: false
status: declined

There is no patch_apply_end event with success: true in the session. Despite that, a Git worktree that was clean before the patch attempts now contains one modified file with:

30 insertions, 2 deletions

The remaining worktree diff is only an initial subset of the larger intended patch described in the rejected event's changes payload. Later hunks from the intended patch are absent. This means the failed operation was not atomic, and the reported tool result does not reflect the filesystem state.

This is related to #34872, which reports the same automatic-review Responses-Lite 400 error. This report is specifically about the separate integrity/atomicity problem: a rejected built-in edit can leave a partial modification behind.

What steps can reproduce the bug?

1. Start with a clean Git worktree in Codex Desktop on Windows.
2. Use an interactive approval configuration:

``toml
sandbox_mode = "read-only"
approval_policy = "on-request"
``

The active task routes approval-required operations through automatic review.

1. Ask Codex to update one existing source file using the built-in apply_patch operation. The observed target was a CRLF Java source file.
2. Explicitly approve the requested operation.
3. Observe that automatic approval review fails with the X-OpenAI-Internal-Codex-Responses-Lite 400 error and the patch operation is reported as declined.
4. Run git status --short and git diff --numstat.
5. Observe that the target file has nevertheless been modified, with only part of the intended patch present.

Diagnostic session and turn IDs are available privately to OpenAI maintainers on request.

What is the expected behavior?

If the approval reviewer fails and apply_patch returns success: false / status: declined, the workspace must remain unchanged.

Patch application should be atomic: either all intended hunks are committed and the operation reports success, or no hunks are written. If rollback is impossible, the tool result must clearly report the exact partial filesystem changes so the user and agent do not incorrectly assume that the worktree is unchanged.

Additional information

• The worktree was checked as clean before the patch attempts.
• After the rejected attempts, exactly one source file was modified (+30/-2).
• No project source code, repository name, or user path is included in this report.
• I did not run further destructive or workaround write probes after finding the unexpected partial modification.
• Related approval-review reports: #34872 and #25617.

The integrity impact is that users and agents may trust the declined result and continue from an inconsistent or uncompilable worktree. A failure in an approval/safety layer should not silently leave a subset of a rejected edit on disk.