[Windows Desktop 26.803.5235.0] git.exe crashes with “memory could not be read” and worktree operations hang

[feoyang]

What version of the Codex App are you using?

• Codex Desktop: 26.803.5235.0
• Command runner observed locally: codex-command-runner-0.147.0-alpha.6.5.exe

What platform is your computer?

• Windows x64 (Chinese UI)
• Native Windows workspace, not WSL
• External Git for Windows: 2.54.0.windows.1
• Codex bundled Git for Windows: 2.53.0.windows.3
• The opened workspace is a parent directory containing multiple independent Git repositories and worktrees.

What issue are you seeing?

While Codex Desktop is executing repository tasks, Windows repeatedly displays a native crash dialog for git.exe:

git.exe - Application Error
The instruction at 0x... referenced memory at 0x0000000000000000. The memory could not be read.

This happened more than once during the same task.

The most reproducible trigger was a git worktree add operation initiated through Codex. With the external Git executable, the operation failed/hung and showed the native crash dialog. I then explicitly tried the Git executable bundled with Codex; it printed:

Preparing worktree (checking out '<branch>')

and then remained stuck. Three child git.exe processes with the same start time were left running and had to be terminated after inspection.

A later crash dialog appeared while the foreground command being run by Codex was PowerShell-only and did not invoke Git. This suggests that the dialog may come from a previously stuck/orphaned Git child or from a background repository watcher, rather than necessarily from the currently displayed command.

Git is stable when used manually in PowerShell and when the same repositories are used from Cursor and Claude Code. The issue has only been observed while Codex Desktop is running tasks.

At the time of inspection, the system still had roughly 9 GB of available physical memory and commit usage was well below the system commit limit, so this occurrence was not explained by immediate system memory exhaustion.

Both the PATH-selected Git and Codex's bundled Git showed the hang/failure behavior, so changing only the Git executable did not resolve it.

Windows Event Viewer did not contain a readable matching Application Error event for these occurrences, so I do not have a confirmed faulting module or exception code. Screenshots of the two native dialogs are available if maintainers need them.

What steps can reproduce the bug?

The problem is intermittent, but the observed sequence was:

1. Open Codex Desktop on Windows.
2. Open a parent workspace containing multiple independent Git repositories/worktrees.
3. Ask Codex to inspect repositories and create a new Git worktree.
4. Codex runs git worktree add.
5. The operation stalls after the "Preparing worktree" message.
6. One or more git.exe processes remain alive.
7. Windows shows a git.exe - Application Error dialog saying that address 0x0000000000000000 could not be read.
8. The dialog can appear again during a later, non-Git foreground command.

What is the expected behavior?

• Git operations initiated by Codex should complete or fail with a bounded timeout and an actionable error.
• Codex should reap cancelled or failed Git child processes.
• Repository background scanning should use backoff/concurrency limits and should not continue launching Git operations after a failure.
• A Git child crash should be reported inside Codex without displaying repeated native Windows crash dialogs.

Troubleshooting already attempted

• Confirmed that manual Git usage outside Codex works normally.
• Switched from external Git 2.54.0.windows.1 to Codex's bundled Git 2.53.0.windows.3; the operation still hung.
• Inspected and terminated only the Git child processes created at the exact time of the stuck worktree operation.
• Checked available memory/commit usage; the machine was not near its limit at the time.
• Queried Windows Application events for matching git.exe failures, but no corresponding event was available.

Current workaround

• Fully exit Codex Desktop to stop repository watchers and clear orphaned children.
• Open each Git repository as a separate Codex workspace instead of opening their shared parent directory.
• Avoid creating/removing Git worktrees from Codex Desktop; perform those operations in a normal terminal and reopen the repository afterward.

Possibly related issues

• Windows Codex App 26.519.11010.0 flashes git.exe console windows during tasks #24910 — Git 2.54.0 works in PowerShell but Codex tasks flash/show git.exe windows
• [Critical][Windows Desktop 26.721.4979.0] runaway background Git loop exhausts system commit, crashes DWM, and forces reboot #35776 — background Git loop and repeated git.exe access violations on Windows
• [Windows Desktop 26.721.3996.0] codex.exe 0xc0000409 crash triggered by Git repository detection; hiding .git prevents it #35179 — Git repository detection / git-repo-watcher triggers crashes
• Codex App (Windows): an unresolvable git root causes an unbounded, no-backoff retry loop that saturates the entire machine — 142/168 git calls hit the 60s timeout #34473 — unresolvable Git root causes an unbounded no-backoff retry loop
• Windows Codex app repeatedly spawns git.exe/conhost.exe in Git workspaces, possibly contributing to Nonpaged Pool growth #26812 — repeated git.exe / conhost.exe spawning in Git workspaces
• Codex Windows App keeps spawning git.exe status --porcelain=v1 -z and leaves orphan git.exe / conhost.exe processes #17229 — orphaned git.exe status / conhost.exe processes

Privacy note

Local usernames, repository names, branch names, and full private paths have been removed from this report.