failing to write newlines with apply_patch because of mixed CRLF; fallback to (very slow) python
Open 💬 7 comments Opened Jan 26, 2026 by kalineh
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.88.0
What subscription do you have?
plus
Which model were you using?
5.2 high
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
git bash
What issue are you seeing?
apply_patch fails to handle newlines and it falls back to writing edits with python but it's extremely token-intensive and slow
What steps can reproduce the bug?
Uploaded thread: 019bf62c-2d0e-72f3-a76d-8f60b5f285b5
just make some files in windows with CRLF
have codex make some edits (it will write LF only)
have it do some later edits on spans that mix CRLF and LF
sometimes it works, sometimes it fails
What is the expected behavior?
apply_patch is robust to newlines of any kind
add local setting to force writing CRLF for windows (its actually a nightmare with diffs and git and stuff for it to write LF only)
Additional information
_No response_
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Probably related to this problem that I reported in the past: https://github.com/openai/codex/issues/4003.
I am running into this issue all the time since many weeks. Often when Codex attempts to patch some file, the diff fails to apply (apparently due to unexpected line endings) and Codex requires multiple attempts and workarounds until it manages to patch files (via cumbersome workarounds like Python or other means). So in the end, it usually manages to apply the patches but it burns through a lot of tokens.
Also encountered same problem. Extremely annoying! And fantastically slow, almost unusable when it starts flailing around with Python.
I’d like to propose adding explicit line-ending control to
apply_patch.Today, inserted/replaced lines are written with
LF. On Windows repos this can create mixed-line-ending files when the target file usesCRLF, even when repo instructions such asAGENTS.mdor.editorconfigrequire preserving line endings.Suggested design:
Add a global setting:
"default_apply_patch_line_endings": "lf" | "crlf" | "preserve" | "raw"For backward compatibility, the built-in default should remain:
"default_apply_patch_line_endings": "lf"Add an optional per-call argument:
"line_endings": "global" | "lf" | "crlf" | "preserve" | "raw"The per-call default would be:
"line_endings": "global"Meanings:
global: usedefault_apply_patch_line_endingslf: insert\ncrlf: insert\r\npreserve: detect and use the target file’s dominant existing line endingraw: preserve line-ending bytes exactly as provided in the patch payloadThis keeps existing behavior unchanged while allowing agents to follow repo-level instructions without needing a separate normalization command after every patch.
I tested possible workarounds: textual
\ris written literally as5C 72, and an actual0Dat the end of a patch line was not preserved; the inserted line still ended with only0A. So this seems to need tool-level support.Great idea! This is still causing immense aggravation for us Windows users.
I am facing this issue on Windows as well. My files use
CRLF. Every time the model uses theapply_patchtool it usesLFendings so the file ends up withMIXEDline endings. It also always deletes the trailing newline in my files. I have to instruct the model to manually restore the trailing newline AND to normalize line endings back toCRLF.Could we get a fix for this please? The code seems to be in lib.rs.