›_ Codex Issues
Codex Issues / #24681

Codex Desktop on Windows can leave git diff --numstat readers causing user-mapped section write failures during edits

Open 💬 6 comments Opened May 27, 2026 by FixAdmin
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.519

What subscription do you have?

plus

What platform is your computer?

windows 10

What issue are you seeing?

On Windows, Codex Desktop intermittently fails to rewrite files in a Git worktree with:

The requested operation cannot be performed on a file with a user-mapped section open.

In my case this was caused by Codex Desktop background Git diff processes, not by my application code.

Codex was spawning long-running commands like:

git diff --no-ext-diff --no-textconv --color=never ... --find-renames --numstat -z

Observed process chain:

Codex.exe
-> Python313\Scripts\git.exe
-> C:\Program Files\Git\cmd\git.exe
-> mingw64\bin\git.exe

While these Codex-spawned git diff --numstat --find-renames processes were alive, normal source rewrites failed. PowerToys File Locksmith showed no normal file holder, and exclusive-open diagnostics could report exclusive_open=ok.

Killing only those Codex-spawned git diff processes made the same file rewrite succeed immediately.

The issue was amplified because Codex Desktop's Environment / Changes counter was showing about 1.5 million changed lines due to a stale base/ref, while the actual working diff shown elsewhere was small.

What steps can reproduce the bug?

  1. Open a Git worktree in Codex Desktop on Windows.
  1. Let Codex Desktop compute the Environment / Changes counter.
  1. Get into a state where the Environment counter is using a stale or unexpectedly large base/ref. In my case it showed about 1.5 million changed lines, even though the actual working diff was small.
  1. Observe Codex-spawned background Git processes like:

git diff --no-ext-diff --no-textconv --color=never ... --find-renames --numstat -z

  1. While those git diff --numstat --find-renames processes are still running, ask the agent to edit or rewrite source files in the worktree.
  1. The write can fail with:

The requested operation cannot be performed on a file with a user-mapped section open.

  1. Kill only the Codex-spawned git diff --numstat --find-renames processes.
  1. Retry the same file edit.
  1. The rewrite succeeds immediately.

What is the expected behavior?

Codex Desktop should not allow background Git diff readers to block agent file edits on Windows.

Expected behavior:

  • Background git diff --numstat scans should be cancelled, sequenced, or avoided before applying patches / rewriting files.
  • Codex should avoid holding long-lived mapped reads over files that the agent may rewrite.
  • The Environment / Changes counter should not repeatedly compute a stale huge branch/base diff when the actual working diff is small.
  • Codex should expose which base/ref the Environment / Changes counter is using, so stale-base problems are diagnosable.

Additional information

This reproduced in Codex Desktop on Windows.

The failing writes included source files such as:

src-tauri/src/lib.rs
src-tauri/src/game_studio/kanban_adapter.rs

Important observations:

  • This was not caused by my application code.
  • This was not a typical file lock visible in PowerToys File Locksmith.
  • File Locksmith showed no normal process holding the file.
  • An exclusive-open probe could still report exclusive_open=ok.
  • The failure reproduced specifically while Codex background git diff --numstat --find-renames processes were running.
  • Killing those diff processes cleared the immediate write failure.
  • Fixing the stale Git base/ref so the Environment / Changes counter collapsed also made the issue stop happening during normal work.

The Environment / Changes counter showed about 1.5 million changed lines, while the actual working diff was small. That caused repeated heavy background diff scans and made the Windows mapped-section write failure much more likely.

Suggested mitigation:

Codex Desktop should cancel or sequence background git diff --numstat scans before applying patches on Windows, especially when using --numstat -z --find-renames.

It would also help if Codex showed the base/ref used by the Environment / Changes counter.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23809

Powered by Codex Action

FixAdmin · 3 months ago

This is related to #23809, but I do not think it is an exact duplicate.

#23809 describes the incorrect Git panel comparison base.

This issue describes the downstream Windows failure mode caused by that behavior: Codex-spawned background git diff --numstat --find-renames processes can keep mapped reads alive long enough for normal agent file rewrites to fail with:

The requested operation cannot be performed on a file with a user-mapped section open.

So even if the stale base/ref problem is fixed, Codex Desktop should also cancel or sequence background Git diff readers before applying patches on Windows.

suiyuebaobao · 1 month ago

The lingering git diff --numstat readers here are part of the same Git-backed desktop integration surface that this workaround disables.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.

buyeXX · 1 month ago

Additional reproduction: stale Desktop review base blocks external IDE saves

I am seeing the same Windows mapped-section failure, with an additional trigger and user-visible impact: after a branch change, Codex Desktop keeps using an old review base and the resulting background Git work intermittently prevents JetBrains Rider and VS Code from saving source files.

Environment

  • Windows x64, build 26200.8875
  • JetBrains Rider 2026.1 and VS Code
  • Original failure reproduced while using Codex Desktop 26.715.7063.0
  • The same review-summary abort pattern remained present locally on 26.715.8383.0, 26.715.9079.0, and 26.715.9868.0
  • Current installed version is 26.715.10079.0; it is too new for me to claim whether the issue is fixed there

Repository names, branch names, local paths, usernames, and private commit SHAs are redacted below.

Reproduction sequence

  1. Create or continue a long-lived Codex Desktop task while branch A is checked out.
  2. Switch the same local checkout to branch B.
  3. Continue using the existing Desktop task.
  4. Desktop's review_model continues comparing the worktree against the old fixed SHA from branch A instead of resolving the comparison base for branch B.
  5. In this reproduction, the retained base was 1,306 commits behind HEAD, while the correct integration-branch comparison was only 3 commits.
  6. Desktop repeatedly ran commands shaped like:

``text
git diff ... <stale-base-sha> --find-renames --raw --numstat -z
``

  1. While editing a Lua source file in Rider or VS Code, saving intermittently failed. Rider showed:

``text
Cannot save <redacted-source-file>
Unable to open the file for writing.
``

The underlying Windows error recorded by Rider was:

``text
ERROR_USER_MAPPED_FILE (1224)
The requested operation cannot be performed on a file with a user-mapped section open.
``

  1. Notepad++ could save the same file, apparently because its write strategy did not collide with the mapped section in the same way.

The failure persisted after disabling Copilot, uninstalling the previously suspected endpoint/XDR product, rebooting Windows, and reproducing again. File attributes and ACLs were normal.

Desktop log evidence

The Desktop logs repeatedly contained:

requestKind=review-summary
source=review_model
failureReason=aborted
failureReason=abortedBeforeStart

Recent local counts:

| Desktop build | review-summary rows | abort/failure rows |
|---|---:|---:|
| 26.715.8383.0 | 160 | 160 |
| 26.715.9079.0 | 53 | 54 |
| 26.715.9868.0 | 279 | 283 |

Rider logs and Procmon confirmed the mapped-file failure and Git file-mapping activity at save time. Separately, the Codex Desktop logs confirmed the stale-base review-summary loop. The combined evidence is consistent with the oversized Codex diff substantially extending the Windows file-mapping conflict window. I am not claiming that every failed save was independently tied to one exact Codex PID in the sanitized capture.

Expected behavior

  • Invalidate and recompute the review/Changes base whenever the branch, worktree, associated PR base, or checkout changes.
  • Validate any retained base against the live repository graph before running a broad diff.
  • Coalesce/debounce overlapping review-summary refreshes.
  • When a refresh is cancelled, terminate and reap the complete Git process tree before starting another one.
  • Avoid leaving mapped Git readers active while external editors may perform safe-write/replace operations.
  • Expose the current comparison base and provide a way to disable background review refresh for a workspace.

Related issues

  • #23809: wrong Desktop Git comparison base
  • #30741 and #30751: stale merge-base in review flows
  • #30820: eager/repeated Desktop review-summary snapshots

This reproduction connects those stale-base behaviors to the external-editor write failure tracked here: Rider and VS Code can become unable to save ordinary source files while Codex Desktop remains open.

yfwang1027-cmyk · 1 month ago

Additional confirmed reproduction for openai/codex#24681.

Environment:

  • Codex Desktop 26.715.10079.0
  • Windows x64
  • Git for Windows
  • External editor: FairyGUI

FairyGUI intermittently fails File.WriteAllText with:

Win32 IO returned 1224
The requested operation cannot be performed on a file with a user-mapped section open.

Process Monitor confirmed the source:

ChatGPT.exe
-> C:\Program Files\Git\cmd\git.exe
-> C:\Program Files\Git\mingw64\bin\git.exe
-> git diff ... --find-renames --raw --numstat -z
-> CreateFileMapping(PAGE_READONLY)

During one 26-second capture, Codex started 10 Git diff scans.

Confirmed collision timeline:

  • 11:57:35.328: Codex Git creates a read-only file mapping
  • 11:57:35.553: FairyGUI attempts to save the XML and cannot open/truncate it
  • 11:57:35.566: Git releases the mapping
  • 11:57:35.918: FairyGUI retries and saves successfully

All mapped Git processes had ChatGPT.exe as their ancestor. The issue also
reproduced with Fork closed and does not require an extremely large diff.

Please debounce/cancel background diff scans, avoid mapped reads that block
external safe-write/truncate operations on Windows, or provide a workspace
setting to disable background Changes/review refresh.

Memo-Git · 16 days ago

Additional confirmed reproduction on Codex Desktop 26.803.10989.0 (Unity / HybridCLR)

This issue still reproduces on a current Windows Codex Desktop build.

Environment

  • Windows 11 Pro x64, version 10.0.22631
  • Codex Desktop 26.803.10989.0
  • Git for Windows 2.52.0.windows.1
  • Unity 2021.3.57f2
  • Writer: HybridCLR GenericReferenceWriter.Write -> System.IO.File.WriteAllText
  • Generated tracked file: Assets/HybridCLRGenerate/AOTGenericReferences.cs

Failure

System.IO.IOException: Win32 IO returned 1224
Path: <repo>/Assets/HybridCLRGenerate/AOTGenericReferences.cs
...
System.IO.File.WriteAllText(...)
HybridCLR.Editor.AOT.GenericReferenceWriter.Write(...)
HybridCLR.Editor.Commands.AOTReferenceGeneratorCommand.GenerateAOTGenericReference(...)
HybridCLR.Editor.Commands.PrebuildCommand.GenerateAll()

Windows error 1224 corresponds to:

ERROR_USER_MAPPED_FILE
The requested operation cannot be performed on a file with a user-mapped section open.

Fresh trace evidence

A fresh 12-second ETW capture immediately after the failure observed git.exe mapping that exact generated C# file three times. The individual mapping intervals lasted approximately 0.68 to 1.25 seconds.

The outer Git process was spawned by Codex Desktop's ChatGPT.exe, using a command shaped like:

git diff ... <base-sha> --find-renames --raw --no-abbrev --numstat -z

The target file was tracked and modified. The worktree had approximately 130 tracked changes, so this reproduction did not require the extremely large million-line diff described in the original report.

An earlier capture on the same machine established the stronger timing correlation: the write failure occurred inside Git file-mapping intervals. An isolated A/B test also reproduced error 1224 only when a concurrent Git reader was active; the same writes succeeded 500/500 without it.

This was first confirmed on this machine with Codex Desktop 26.715.9757.0 and remains reproducible on 26.803.10989.0.

Requested mitigation

In addition to coalescing scans, please consider:

  • A per-workspace setting to disable background Changes/review Git scanning.
  • Workspace path exclusions for generated output directories.
  • Cancelling and fully reaping background Git process trees before write/patch operations.
  • Avoiding Windows mapped-file reads that prevent truncate/replace operations on tracked generated files.

No raw ETW trace or private repository path is attached; the values above are sanitized observations.