Codex Desktop treats review-only feedback as authorization to edit workspace files

Summary

Codex Desktop initiated an implementation workflow in response to an explicitly review-only request.

The reporter had previously established—and received acknowledgement—that terms such as “feedback,” “analysis,” and “review” authorize inspection and recommendations only. File changes require an explicit action such as “implement,” “fix,” “edit,” or “apply.”

A later prompt began with “feedback on” and described two visible navigation problems, with screenshots. Codex then:

1. announced that it would modify the implementation;
2. loaded an implementation-oriented workflow;
3. prepared and attempted a multi-file patch; and
4. requested elevated execution after the first write attempt was blocked.

The user rejected the elevated request. No files were changed.

Environment

• Codex Desktop: 26.707.8479.0
• Bundled Codex CLI: 0.137.0
• OS: Windows 11 x64 (Microsoft Windows NT 10.0.26200.0)
• Permission mode: Ask for approval / workspace-write
• Native Windows Desktop session
• Observed: July 13, 2026

Observed sequence

1. Establish the task-level rule that “feedback,” “analysis,” and “review” are read-only.
2. Receive explicit acknowledgement from Codex.
3. Later provide UI feedback using a prompt beginning with “feedback on,” without requesting a fix or implementation.
4. Observe Codex enter an implementation workflow and attempt workspace edits.
5. When the write mechanism encounters a sandbox error, observe Codex request elevated execution rather than returning to the original task-authorization boundary.
6. Reject the escalation.
7. Confirm that no files changed.

This sequence has been observed once with screenshots. Model behavior may make reproduction nondeterministic.

Actual behavior

Codex inferred authorization to implement from the surrounding build context and the specificity of the feedback.

The workspace-write sandbox would have allowed the edits without an additional prompt if the initial patch operation had succeeded.

The later escalation prompt concerned technical sandbox access; it did not correct the absence of task-level authorization.

Expected behavior

Task authorization and sandbox capability should remain separate:

• Workspace-write determines where authorized edits may occur.
• The user’s current request determines whether edits are authorized at all.
• Escalation approval determines whether an already-authorized action may cross a technical boundary.

Review-only language should permit inspection, diagnosis, browser verification, and recommendations, but should not initiate file mutations or implementation workflows.

Prior build context should not convert a later review request into implicit authorization to change files.

Before any mutating tool call—and again before requesting elevated access—Codex should verify that the current request contains explicit implementation authority.

Impact

• Users cannot safely request feedback while retaining workspace-write for normal development.
• A review request can silently become a modification request.
• Users must either monitor every tool call or repeatedly switch permission profiles.
• Sandbox controls are incorrectly made responsible for compensating for task-intent failures.
• A successful in-workspace edit may occur before the user receives any approval prompt.

Scope boundary

This report is not claiming that workspace-write incorrectly permits workspace edits. That is its documented technical behavior.

The defect is that Codex selected an edit workflow when the user had authorized review only.

No files were changed in the observed incident because the initial patch failed and the user rejected the subsequent escalation.

Possibly related

• #8643 — explicit “never touch git” instruction ignored, causing data loss.
• #3710 — request for separate read and write approval policies.
• #11915 — read-only approval-mode behavior.

These involve adjacent permission concerns but do not cover this task-authorization failure.