Windows: apply_patch fails for large patches because patch body is still transported via argv

Open 💬 3 comments Opened Mar 18, 2026 by aisubscriptionshare-debug

What version of Codex CLI is running?

0.115

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

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, sufficiently large apply_patch invocations fail before patch application begins.

This looks like a patch transport problem rather than a patch parser problem.

In my usage, this was only occasional with gpt-5.3-codex, because the generated edits tended to be shorter. With gpt-5.4, the problem becomes much more frequent because the model often generates 1000+ lines of code in a single edit.

When that first large apply_patch fails, Codex often tries to recover by splitting the same logical change into 4-5 smaller apply_patch calls. That sometimes avoids the Windows size limit, but it also burns tokens very quickly for what should have been one edit.

So this is not just a reliability bug. It also has a real cost impact on Windows because one failed large patch can turn into several extra retries.

The underlying error I see is:

``text ✘ Failed to apply patch └ execution error: Io(Os { code: 206, kind: InvalidFilename, message: "파일 이름이나 확장명이 너무 깁니다." })``
From a user perspective, Codex still cannot reliably apply large patches on Windows.

What steps can reproduce the bug?

Start codex on Windows in an empty or temporary working directory.
Use gpt-5.4.
Ask Codex to create or rewrite a file with 1000+ lines using apply_patch, for example:

"Create big.ts with 1200 lines of code"
"Generate a full implementation in one file and apply it with apply_patch"

Codex often emits one large apply_patch.
The patch fails before application starts.
After that, Codex often retries by splitting the same logical change into several smaller apply_patch calls, which increases token usage significantly.

A lower-level repro from within the same Codex session is:

```powershell
$tmp = Join-Path $env:TEMP 'codex-apply-patch-repro'
New-Item -ItemType Directory -Force -Path $tmp | Out-Null
Set-Location $tmp

$lines = 1..1200 | ForEach-Object { "+line-$('{0:D4}' -f $_)-" + ('x' * 20) }
$patch = " Begin Patchn*** Add File: big.txtn" + ($lines -join "n") + "n End Patch"

apply_patch $patch
```

For me this fails before patch application starts, and big.txt is not created.

What is the expected behavior?

apply_patch should work for large patches on Windows and should not depend on Windows command-line length limits.

The patch body should be transported independently of argv, for example via stdin or a temporary file.

A single logical edit should not require multiple follow-up apply_patch retries just to work around Windows command-line size limits.

The practical limit should be patch correctness, not command-line payload size.

Additional information

As of 2026-03-18, this appears to be a pure upstream Codex implementation issue.

The current official source still appears to do the following on Windows:

create apply_patch.bat
forward the patch body through %*
dispatch the internal apply-patch path by reading the patch body from the next argv element

Small relevant code fragments from codex-rs/arg0/src/lib.rs are effectively:

``text "codex.exe" --codex-run-as-apply-patch %*``

and later:

let patch_arg = args.next()

That is why this looks like a transport-layer issue on Windows.

codex-rs/apply-patch/src/invocation.rs already parses supported direct and heredoc-style apply_patch forms, which is why I do not think the parser is the primary problem here.

So the real issue is not "1000 lines" specifically. The real issue is that the patch body is still transported over argv on Windows.

There are effectively two Windows limits involved:

the .bat / cmd.exe command-line limit
the native process argument limit, because the patch body is still carried in argv

A likely fix would be to stop passing the full patch body as a command-line argument and instead use either:

stdin
a temporary patch file

Relevant source files:

View original on GitHub ↗

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