Windows/pwsh: apply_patch.bat breaks multiline patch arguments; direct codex.exe --codex-run-as-apply-patch succeeds with the same patch

Open 💬 4 comments Opened Mar 7, 2026 by doraemonkeys

What version of Codex CLI is running?

codex-cli 0.111.0

What subscription do you have?

plus

Which model were you using?

gpt-4.5

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

PowerShell 7.5.4

What issue are you seeing?

On Windows with PowerShell, apply_patch fails for valid multiline patch strings when invoked through
apply_patch.bat. The exact same patch succeeds when passed directly to codex.exe --codex-run-as-apply-patch, which
suggests the Windows wrapper is corrupting or truncating multiline arguments during forwarding. The observed error is:
Invalid patch: The last line of the patch must be '*** End Patch'.

What steps can reproduce the bug?

  1. Run Codex CLI on Windows in PowerShell.
  2. Check which executable is actually being used for apply_patch:

``powershell
Get-Command apply_patch
Get-Content -Raw (Get-Command apply_patch).Path
``

On my machine this resolves to a temporary wrapper like:

``text
C:\Users\xxx\.codex\tmp\arg0\codex-arg0ARnQri\apply_patch.bat
``

and the wrapper contains:

``bat
@echo off
"...\codex.exe" --codex-run-as-apply-patch %*
``

  1. Prepare a multiline patch string in PowerShell:

``powershell
$patch = @"
*** Begin Patch
*** Add File: hello.txt
+hello
*** End Patch
"@
``

  1. Invoke the wrapper entrypoint:

``powershell
apply_patch $patch
``

On my machine this fails with:

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

  1. Invoke the underlying executable directly with the exact same $patch value:

``powershell
$codexExe = "...path extracted from the wrapper..."
& $codexExe --codex-run-as-apply-patch $patch
``

On my machine this succeeds and creates hello.txt.

What is the expected behavior?

apply_patch should be a reliable Windows entrypoint for multiline patch content.

If Codex uses a Windows shim or wrapper, it should preserve the patch argument exactly, including embedded newlines. Agents and workers that are instructed to edit files via apply_patch should not be blocked by shell-wrapper behavior.

What do you see instead?

A valid-looking multiline patch fails when sent through apply_patch.bat, but the identical patch succeeds when passed directly to codex.exe --codex-run-as-apply-patch.

That makes this look like a Windows wrapper / argument-forwarding bug, not a patch-format bug in the payload itself.

Additional information

I verified this locally on the same machine using the same patch content and saw different results depending only on the entrypoint:

  • apply_patch $patch failed
  • codex.exe --codex-run-as-apply-patch $patch succeeded

That isolates the behavior difference to the Windows wrapper path.

This matters because Codex agents are often instructed to edit files via apply_patch. On Windows/PowerShell, that becomes brittle if the wrapper forwards multiline arguments via %* and does not preserve them losslessly.

Potential fix directions:

  • Bypass the .bat wrapper and expose a native executable entrypoint for apply_patch on Windows.
  • Pass patch content via stdin, a temp file, or another transport that does not depend on %* preserving multiline payloads.
  • Change the Windows shim implementation so multiline arguments survive forwarding intact.

Additional information

Related issues:

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗