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

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

• #24910 — Git 2.54.0 works in PowerShell but Codex tasks flash/show git.exe windows
• #35776 — background Git loop and repeated git.exe access violations on Windows
• #35179 — Git repository detection / git-repo-watcher triggers crashes
• #34473 — unresolvable Git root causes an unbounded no-backoff retry loop
• #26812 — repeated git.exe / conhost.exe spawning in Git workspaces
• #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.

Begin with the Windows git worktree add path and the repository background watcher/child-process lifecycle. Reproduce the stalled operation in a parent workspace containing multiple repositories, then inspect cancellation, timeout, and child-process cleanup behavior. Done means Git failures are bounded and actionable, orphaned processes are reaped, and repeated native crash dialogs do not occur.