error: Failed to apply patch
No complete upstream fix exists. Restart the session — close the failing instance and reopen with `codex resume`; files that repeatedly failed to patch usually apply cleanly after, per reports on the open GitHub issue. Never run in read-only sandbox mode, which blocks all file writes by design. On Windows or with CJK text, reports point to an encoding bug — force the console to UTF-8 (`chcp 65001`) and keep files UTF-8. Otherwise the model retries its way through at token cost.
Affected versions: reports span codex-cli 0.38.0 (Sep 2025) through 0.104/0.105 (Feb 2026) and later; no fixed-in version confirmed
Codex edits files through its apply_patch tool, and when the patch it generates does not match the file on disk — or the sandbox blocks the write — the turn ends in ✘ Failed to apply patch. This is a chronic failure class, not a one-off bug: a tracker search returns eleven open issues at last count, spread across the CLI, the VS Code extension, and the Windows desktop app.
Symptoms
- An edit fails with
✘ Failed to apply patch, and the agent retries the same change — one September 2025 report put it at “3+ attempts to apply edits”. - Specific files fail on every attempt within a session while other edits land fine (#12241).
- Retries burn tokens: a commenter on #12241 measured an identical prompt jumping from $0.26 to $1.51 once patch failures kicked in — spend that counts against your usage limits.
- On Windows with non-ASCII content, the failure arrives with mojibake (a forum thread shows Turkish text corrupted into patch anchors that can never match) or a hard panic — #9580 reports
byte index 200 is not a char boundaryon Chinese characters.
Cause
There is no single root cause on record — this error is a cluster. An OpenAI engineer said on #12241 that apply_patch was disabled for gpt-5 “because the model was not trained on it,” while the model can still remember the tool from training and call it in ways the harness rejects — behavior that varies by model. A reporter on the same thread traced their failures to upgrading the CLI and then resuming an old session (user report, not maintainer-confirmed). On Windows, wrong-codepage reads corrupt the context lines a patch anchors to (forum thread), and CJK characters can panic the sandbox mid-patch (#9580).
Fix
- Restart the session. Close the failing instance and reopen with
codex resume— an April 2026 commenter on #12241 reported files that had failed repeatedly applied cleanly after: “I didn’t see any ✘ Failed to apply patch after that.” - Get out of read-only sandbox mode. Read-only blocks local writes by design, so every patch fails; use
workspace-writefor editing work. - On Windows or with non-ASCII files, fix encoding. The forum thread points to forcing the console to UTF-8 (
chcp 65001plus PowerShell’s$OutputEncoding) and keeping source files UTF-8. - Check whether an update caused it. One #12241 reporter fixed constant 0.104 failures by downgrading to 0.103; OpenAI staff said no other users had reported it. Start a fresh session after any version change.
- Expect self-recovery at a cost. The model usually rewrites the patch and gets it through after retries — the failure mode is wasted tokens more than lost work.
Affected versions
Reports span codex-cli 0.38.0 (September 2025), 0.87.0, and 0.104/0.105 (February 2026), with newer reports still arriving on the open tracker search. No release note marks this class of error fixed.
Facts on this page verified July 15, 2026.
- openai/codex #12241 — 'Failed to apply patch constantly' (open; restart workaround, OpenAI responses)
- openai/codex #3858 — 'Increased Failed to apply patch errors' (closed, Sep 2025)
- openai/codex #9580 — 'Failed to apply patch due to encoding issues' (open; Windows/CJK panic)
- OpenAI community forum — Codex on Windows: UTF-8 mojibake and patch-context mismatch
- openai/codex issue tracker — open 'failed to apply patch' reports
- OpenAI docs — Codex sandboxing (read-only / workspace-write / danger-full-access)