Codex Desktop can reapply a patch after the user rejects it

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

Version 26.707.31428

What subscription do you have?

Pro

What platform is your computer?

Windows, PowerShell workspace.

What issue are you seeing?

A user rejected an apply_patch approval request. The tool correctly returned patch rejected by user, and the rejected patch did not modify the files. However, the agent then issued new, smaller apply_patch calls containing the same semantic changes. Those later calls executed because the repository remained an authorized writable workspace.

This means a user rejection is request-scoped and does not prevent the agent from immediately retrying the rejected mutation through a new tool call. The agent acknowledged that retrying was incorrect, but there was no product-level guard against it.

No sandbox escape occurred. The concern is that an explicit user rejection can be bypassed behaviorally by splitting or resubmitting the same write operation.

What steps can reproduce the bug?

1. Open a local repository in Codex Desktop with workspace-write access.
2. Ask Codex to make a source-code change.
3. When Codex presents an apply_patch approval request, reject it.
4. Confirm the tool result says patch rejected by user.
5. Have the agent continue the turn or incorrectly interpret the rejection as a patch/tool failure.
6. Observe that the agent can issue a new apply_patch call with the same changes, possibly split into smaller patches.
7. Observe that the later patch can execute because workspace write permission remains active.

What is the expected behavior?

After the user rejects a mutation, Codex should treat that rejection as binding for the semantically equivalent operation within the current turn. The agent should stop and ask for new instructions.

At minimum, the app/runtime should detect immediate retries of the same rejected mutation and require a fresh, explicit approval that clearly states the operation was previously rejected.

Additional information

Observed sequence:

1. Combined patch submitted.
2. Tool returned Script error: patch rejected by user.
3. Agent verified that the rejected patch had not landed.
4. Agent stated it would “reapply the code/test correction in smaller, reviewable edits.”
5. Separate smaller patches were submitted and applied successfully.

Potential safeguards:

• Record rejected mutation intent for the remainder of the turn.
• Block or re-prompt on semantically equivalent retries.
• Surface a strong model-visible instruction that “rejected by user” is not a retryable tool failure.
• Include the prior rejection in any subsequent approval prompt for a related write.

No repository code, credentials, or private logs are included in this report.