Codex git.exe Crashes on Windows? Isolate Worktrees

If Codex Desktop stalls at Preparing worktree, leaves several git.exe processes running, or Windows shows a git.exe - Application Error dialog saying memory could not be read, stop the affected Codex workspace before trying another worktree command. Preserve the repository, identify only the Git children created with the stuck operation, and move worktree creation to a normal PowerShell window.

A current Windows report reproduced the hang with both Git for Windows and the Git executable bundled with Codex. Manual Git use outside Codex remained stable. That supports a narrow containment plan: exit Codex, open one repository root at a time, and create or remove worktrees outside the app until the upstream process-lifecycle problem changes. It does not prove that Git itself, Windows memory, or every Codex worktree is broken.

Confirm the Exact Failure

Use this guide when the sequence looks like this:

1. Codex Desktop is running on native Windows, not inside WSL.

2. The selected workspace is a parent folder containing multiple repositories or linked worktrees.

3. A Codex-initiated git worktree add stops after Preparing worktree.

4. Multiple git.exe children remain after the visible command stops progressing.

5. Windows displays a native memory-read error for git.exe, sometimes during a later non-Git task.

6. The same repositories and Git installation work from ordinary PowerShell outside Codex.

The last condition is important. It separates this report from a corrupt repository or generally broken Git installation.

Stop the Workspace Before Touching Git

Save any active edits and wait for running tasks to finish. Then fully close the affected Codex project. If the desktop app will not close, use Task Manager to end only the Codex process that owns that workspace.

Do not immediately delete %USERPROFILE%\.codex, .git, linked worktree directories, or repository files. The current report reproduced the problem with two Git executables, while normal Git remained healthy outside Codex. Deleting state would add risk without testing the observed process boundary.

Open PowerShell and list the remaining Git processes:

Get-CimInstance Win32_Process -Filter "Name = 'git.exe'" |
  Select-Object ProcessId, ParentProcessId, CreationDate, CommandLine

Compare the creation times with the stuck operation. Command lines can contain private paths, branch names, or repository details, so do not paste this raw output into a public report.

If you can tie a remaining process to the exact failed command and Codex is fully closed, stop only that process:

Stop-Process -Id <confirmed-process-id

Repeat the process listing. If unrelated Git commands are running, leave them alone. A broad taskkill /IM git.exe /F can interrupt another editor, terminal, build, or repository operation.

Inspect Worktree State Without Repairing It Yet

Move into the repository that Codex was trying to modify:

Set-Location 'C:\path\to\repository'
git status --short
git worktree list --porcelain
git worktree prune --dry-run --verbose

These commands answer three different questions:

• git status --short shows whether the main worktree has changes that must be preserved;

• git worktree list --porcelain shows the linked worktrees Git currently recognizes; and

• git worktree prune --dry-run --verbose reports stale administrative entries without removing them.

Stop if the working tree has unexpected changes, a target path belongs to another active worktree, or the dry run reports an entry you do not understand. Do not use git worktree remove --force, delete .git/worktrees, or run a real prune merely because Codex left a process behind.

Git's official worktree documentation distinguishes stale metadata from moved worktrees. git worktree repair can reconnect administrative files after paths were moved outside Git, but it is not a generic cure for a hung process. Use it only when git worktree list and the actual paths prove that a worktree was moved or its links are stale.

Create the Worktree Outside Codex

When the repository is clean enough to proceed and no related git.exe remains, create the worktree from ordinary PowerShell while Codex stays closed. For a new branch:

git -C 'C:\path\to\repository' worktree add `
  -b 'task-branch' `
  'C:\path\to\repository-task' `
  HEAD

Choose an unused branch and an empty target path. If the branch already exists, omit -b and pass the existing branch as the final argument instead. Do not force a branch that Git says is already checked out elsewhere.

Verify the result before reopening Codex:

git -C 'C:\path\to\repository' worktree list --porcelain
git -C 'C:\path\to\repository-task' status --short

Expected result: both commands return promptly, the new path appears once, and the new worktree has the intended branch and clean status.

Open One Repository Root at a Time

The source report used a parent workspace containing multiple independent repositories and worktrees. Until the bug is understood, open the exact repository or linked worktree root in Codex instead of their shared parent directory.

This changes the discovery boundary without modifying Git metadata. It also gives you a clean control:

1. Keep Codex closed while creating the worktree.

2. Open only C:\path\to\repository-task in Codex.

3. Let the project sit idle for two minutes.

4. Check Task Manager or the earlier process query for repeated git.exe children.

5. Run one read-only task such as asking Codex to summarize git status.

If the single-root workspace stays quiet, continue there but keep worktree add, move, remove, prune, and repair operations in a normal terminal. If Git children start repeating again, close that Codex workspace and preserve the process times and non-secret logs for the upstream issue.

Verify Containment

Treat the workaround as successful only when all of these checks pass:

• no git.exe memory-read dialog appears after Codex is closed;

• no orphaned Git process from the failed timestamp remains;

• git worktree list --porcelain returns promptly outside Codex;

• the intended worktree opens cleanly in ordinary PowerShell;

• Codex is opened on one exact repository root, not the shared parent; and

• a read-only Codex task completes without a new Git process loop.

This proves the work can continue through a narrower boundary. It does not prove the underlying Codex bug is fixed.

Avoid Plausible but Destructive False Fixes

Do not switch randomly between bundled and external Git. The current report observed the hang with both, so a version swap alone is not a demonstrated fix.

Do not disable Windows security tools, weaken the Codex sandbox, or exclude an entire development drive from scanning. The report did not establish antivirus or sandbox policy as the cause.

Do not delete a worktree directory in Explorer and then edit .git/worktrees by hand. Git provides list, remove, prune, move, lock, and repair commands specifically to keep the working directory and administrative metadata consistent.

Do not report available RAM as proof of a memory leak. A native access-violation dialog can appear while the system still has free memory. Record the exact fault text and process timing without guessing at the faulting component.

Monitor the Upstream Reports With Aident Loadout

You can check the current issue and related Windows Git-process reports without pasting a GitHub token into chat. Start with this exact instruction:

Follow https://aident.ai/SETUP.md

Then ask:

Check Aident Loadout authentication and Vault status. Search the staging capability catalog for the current GitHub issue search Action, inspect its schema and operation risk, and preflight exact read-only searches for openai/codex issues 37796, 35776, and 35179. If the Action is free and all inputs are valid, execute only those searches and return issue number, state, updated time, labels, comment count, reaction count, title, and canonical URL. Do not comment, react, edit, close, label, publish, expose credentials, run shell commands, or modify a repository.

Success is measurable: the three issue records are current, the output is limited to the requested fields, and GitHub receives no write.

Set up Aident Loadout for bounded issue monitoring.

Report a Useful Reproduction

If the problem returns on a current Codex release, add a sanitized reproduction to the closest upstream issue. Include:

• Codex Desktop and command-runner versions;

• Windows edition, build, and architecture;

• Git for Windows and bundled Git versions tested;

• whether the workspace was one repository or a parent of several repositories;

• the last visible git worktree output;

• count, creation times, and parent process IDs for orphaned git.exe children;

• whether the same command completed outside Codex; and

• the output category from git worktree list --porcelain and prune dry-run.

Remove usernames, private paths, repository and branch names, command arguments with secrets, task text, crash dumps, and raw Codex state. Do not claim that a repository watcher caused the failure unless logs or a maintainer confirm it.

Sources

• OpenAI Codex issue 37796: git.exe memory error and worktree hang on Windows

• OpenAI Codex issue 35776: repeated background Git access violations

• OpenAI Codex issue 35179: repository detection triggers a Windows crash

• OpenAI Codex issue 26904: unbounded Git process spawning on a slow filesystem

• OpenAI Codex issue 20933: parallel git.exe processes and high resource use

• Git worktree documentation

Refresh this guide when issue 37796 changes state, OpenAI changes Windows Git child-process handling, or Git changes worktree recovery commands.