Windows: apply_patch aborts in unelevated sandbox with approval request aborted

Open 💬 1 comment Opened Jul 31, 2026 by k99street-afk

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

Pro Lite

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows PowerShell 5.1

Codex doctor report

Diagnostics and current session logs were uploaded through the Codex feedback feature.

Uploaded thread ID:
019fb89b-77d5-74a2-bfb7-ab2a9751f022

What issue are you seeing?

On Windows, apply_patch fails when trying to create a new file inside the active workspace.

Environment:

  • Codex CLI 0.146.0
  • Also reproduced with npm-installed Codex CLI 0.145.0
  • Workspace: C:\work\leaps-neo
  • Permissions: Workspace / Ask for approval
  • windows.sandbox = "unelevated"

When Codex attempts an Add File patch, the UI displays:

command failed; retry without sandbox?

The session logs contain:

patch_apply_end success:false
status: declined
stderr: approval request aborted

The target file is not created.

The problem reproduced:

  • With an Add File patch of approximately 223 lines
  • With a patch of approximately 39 lines
  • With a minimal patch of only 11 lines
  • In a new Codex session
  • With standalone Codex CLI 0.146.0
  • With npm-installed Codex CLI 0.145.0

Logs under .codex\tmp\arg0 also showed:

os error 5 / Access is denied

The workspace root and current working directory match. The target directory exists, its ACL permits modification, and the file path is not unusually long.

The failure occurs before the patch is applied and appears independent of patch size.

What steps can reproduce the bug?

Uploaded thread: 019fb89b-77d5-74a2-bfb7-ab2a9751f022

What is the expected behavior?

apply_patch should create a new file inside the active trusted workspace while remaining inside the configured Windows sandbox.

It should not require a retry outside the sandbox, and a valid Add File patch should not be recorded as approval request aborted.

Additional information

The same workspace previously allowed successful Add File operations.

The issue is not limited to one installation package:

  • Standalone Codex CLI 0.146.0 reproduced the failure.
  • npm-installed Codex CLI 0.145.0 also reproduced the failure using its matching 0.145.0 --codex-run-as-apply-patch helper.

The target directory ACLs, workspace path, current working directory, and path length appear valid.

A separate elevated-sandbox issue was also observed: Codex reported that codex-windows-sandbox-setup.exe was not found even though the signed helper exists under the installed package's codex-resources directory. I am keeping that as a separate issue from this unelevated apply_patch failure.

Codex feedback and diagnostic logs were uploaded under thread ID:

019fb89b-77d5-74a2-bfb7-ab2a9751f022

View original on GitHub ↗

1 Comment

k99street-afk · 20 days ago

Update: after upgrading to Codex CLI 0.147.0, the minimal sandboxed Add File test succeeded.

Environment:

  • Codex CLI 0.147.0
  • windows.sandbox = "unelevated"
  • Workspace: C:\work\leaps-neo

Result:

  • apply_patch executed once inside the sandbox
  • New file creation succeeded
  • No "retry without sandbox?" prompt
  • No stderr
  • No fallback or second attempt was used

So the specific issue that prevented sandboxed Add File operations appears to be resolved in 0.147.0.

However, running codex --version still produces .codex\tmp\arg0 warnings:

  • stale arg0 temp directory cleanup: Access is denied (os error 5)
  • PATH alias creation: Access is denied (os error 5)

Therefore, the Add File failure is recovered, but the arg0-related warning behavior may still remain.