apply_patch can modify files outside writable roots without an approval prompt

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

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

VS Code integrated terminal on WSL2 (TERM_PROGRAM=vscode). No tmux/zellij.

Codex doctor report

not collected yet

What issue are you seeing?

I observed a filesystem permission-boundary bypass involving the built-in patch/edit path.

In a session running with a workspace-write style sandbox and restricted writable roots, Codex successfully modified ~/.bashrc by appending a block of shell functions, even though ~/.bashrc was outside the declared writable roots and no approval prompt was shown.

The important point is not just that a file outside the workspace was modified, but that the write happened through the patch/edit path with zero approval despite the path being outside the allowed writable roots.

In the same environment, shell-based access to the same target path would normally require escalated approval. So this appears to be inconsistent enforcement between the patch/edit path and normal command execution.

Observed result:

• ~/.bashrc was modified successfully
• no approval prompt was shown
• the target path was outside the writable roots for the session

Expected result:

• the patch should have been blocked, or
• Codex should have requested explicit approval before applying it

What steps can reproduce the bug?

1. Start Codex CLI in a repository with a restricted workspace-write environment where home-directory dotfiles are outside the writable roots.
2. Confirm the writable roots do not include the user home directory or ~/.bashrc.
3. Ask Codex to inspect ~/.bashrc and then append a small shell alias/function block to the end of the file.
4. Observe that the patch/edit succeeds without an approval dialog.
5. Compare this with normal shell behavior against the same path, which should require escalated approval in the same environment.

Repro details from the affected session:

• target file: ~/.bashrc
• sandbox mode: workspace-write style restricted environment
• writable roots did not include the home directory
• the write succeeded anyway with no approval prompt

If useful, I can provide a redacted transcript excerpt showing:

• the declared writable roots
• the successful patch result
• the target path outside those roots

What is the expected behavior?

Writes outside the writable roots should not succeed silently through the patch/edit path.

Approval enforcement should be consistent across:

• built-in patch/edit operations
• shell command writes
• other file mutation paths

If a target file is outside the writable roots, Codex should either block the operation or require explicit approval before applying it.

Additional information

This may be related to prior sandbox / out-of-workspace enforcement reports, but it is not an exact duplicate because this case specifically involves the patch/edit path succeeding on a home-directory dotfile outside writable roots:

• #5203 Sandbox allowed unauthorized out-of-workspace operations despite restrictions
• #11583 Codex bypasses workspace restrictions, edits in other folders with 0 permission requests
• #17018 Sandbox policy inconsistency: Git metadata writes bypass approval after repo root relocation
• #29627 Agent cancels pending manual approvals automatically and treats them as unapproved instead of waiting