Windows sandbox apply_patch wrapper fails: generated .bat points to WindowsApps and corrupts multiline patch args

Summary

On Windows, when Codex is used with the “auto review / approve for me” permission mode, Codex enters the Windows sandbox path. In this mode, apply_patch fails consistently.

The issue appears to be in the generated apply_patch.bat wrapper, not in the patch content, target directory, file encoding, or the underlying codex.exe --codex-run-as-apply-patch implementation.

Two separate problems were observed:

1. The generated apply_patch.bat may point to a WindowsApps packaged codex.exe, which fails with Access is denied.
2. Even when the wrapper is manually changed to point to a working local codex.exe, .bat / .cmd forwarding via %* corrupts multiline patch arguments, causing patch parsing errors.

A PowerShell .ps1 wrapper preserves the multiline patch argument correctly and works both from the shell and from a real codex exec session when placed earlier in PATH.

Environment

• OS: Windows
• Codex CLI version: codex-cli 0.143.0
• Permission mode: “approve for me” / auto review
• Windows sandbox config: [windows].sandbox = "elevated"
• Main Codex entry from PowerShell:

• C:\Users\bart\AppData\Roaming\npm\codex.ps1
• Also present:

• C:\Program Files\WindowsApps\OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
• C:\Users\bart\AppData\Local\OpenAI\Codex\bin\<hash>\codex.exe

Reproduction

Create a clean repro workspace:

mkdir C:\codex-sandbox-probe
cd C:\codex-sandbox-probe
git init

Run Codex in Windows sandbox / auto review mode and ask it to create a file using apply_patch.

Observed failure:

Access is denied.

The generated wrapper was found at:

C:\Users\bart\.codex\tmp\arg0\codex-arg0zmS40N\apply_patch.bat

Its content was effectively:

"C:\Program Files\WindowsApps\OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --codex-run-as-apply-patch %*

Directly invoking that WindowsApps codex.exe also failed with Access is denied.

Additional Findings

A local Codex binary exists and is executable:

C:\Users\bart\AppData\Local\OpenAI\Codex\bin\ea1c60319a1dcb19\codex.exe

Direct call succeeds:

& "C:\Users\bart\AppData\Local\OpenAI\Codex\bin\ea1c60319a1dcb19\codex.exe" --codex-run-as-apply-patch $patch

This successfully created files at multiple directory depths:

local-codex-probe.txt
dir1/probe-1.txt
dir1/probe-2.txt
src/main/java/Probe.java

However, using a .bat or .cmd wrapper around the same local codex.exe fails:

@echo off
"C:\Users\bart\AppData\Local\OpenAI\Codex\bin\ea1c60319a1dcb19\codex.exe" --codex-run-as-apply-patch %*

Failure:

Invalid patch: The last line of the patch must be '*** End Patch'

This suggests that .bat / .cmd argument forwarding via %* corrupts multiline patch arguments.

stdin was also tested:

$patch | & "...\codex.exe" --codex-run-as-apply-patch

It failed with:

Error: --codex-run-as-apply-patch requires a UTF-8 PATCH argument.

So stdin does not appear to be supported for this helper mode.

Working Workaround

A PowerShell wrapper works:

# C:\Users\bart\.codex\bin\apply_patch.ps1
$CodexExe = "C:\Users\bart\AppData\Local\OpenAI\Codex\bin\ea1c60319a1dcb19\codex.exe"

if (-not (Test-Path $CodexExe)) {
  Write-Error "codex.exe not found: $CodexExe"
  exit 1
}

if ($args.Count -lt 1) {
  Write-Error "missing patch argument"
  exit 1
}

& $CodexExe --codex-run-as-apply-patch $args[0]
exit $LASTEXITCODE

Then prepend the wrapper directory to the current PowerShell session PATH before launching Codex:

$env:PATH = "C:\Users\bart\.codex\bin;$env:PATH"
codex

This makes Get-Command apply_patch resolve to:

C:\Users\bart\.codex\bin\apply_patch.ps1

This workaround was also validated in a real Codex non-interactive session:

codex exec -C C:\codex-sandbox-probe "Use apply_patch to add codex-agent-path-probe2.txt with exactly: hello from codex exec path wrapper. Then stop."

Result:

• codex-agent-path-probe2.txt was created successfully.
• File content matched the expected text.
• Codex output showed apply patch completed.

Expected Behavior

Codex-generated apply_patch wrapper on Windows should:

1. Select an executable path that is actually callable from the sandboxed context.
2. Preserve multiline patch arguments exactly.
3. Avoid using .bat / .cmd %* if that corrupts multiline patch content.
4. Prefer a robust mechanism such as a PowerShell wrapper, a native shim executable, or another argument-safe transport.

Actual Behavior

The generated wrapper may:

1. Point to a WindowsApps codex.exe that fails with Access is denied.
2. Use .bat %*, which corrupts multiline patch arguments even if the target codex.exe is otherwise valid.
3. Cause apply_patch to fail under Windows sandbox / auto-review mode.

Impact

This makes normal Codex editing unreliable under the safer Windows sandbox permission mode. The only built-in workaround appears to be using full access, which is too risky for routine development.

Using PowerShell or Python to edit files manually is not a good replacement because it can introduce encoding issues in existing projects.

Suggested Fix

Consider changing the Windows apply_patch wrapper generation strategy:

• Do not generate .bat / .cmd wrappers for multiline patch forwarding.
• Avoid resolving to WindowsApps packaged executables when they cannot be executed from the sandbox context.
• Prefer a PowerShell wrapper, native shim executable, or argument-file based approach that preserves multiline UTF-8 patch content.
• Optionally allow --codex-run-as-apply-patch to read patch content from stdin or a temp file to avoid command-line argument corruption.