[Windows Desktop 26.721.3996.0] codex.exe 0xc0000409 crash triggered by Git repository detection; hiding .git prevents it

Start by reproducing the crash with .git present and absent, then inspect the git-repo-watcher activity and the reported Windows WER minidumps. Compare behavior for unborn and valid HEAD repositories, including the non-ASCII paths described. Done means Git repository detection and watching no longer terminate codex.exe, and errors are handled without a native crash.

Version

• Microsoft Store package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
• An earlier same-day package, 26.721.3404.0, also crashed.
• The regression began immediately after the July 24 update.
• User configuration was unchanged/default.

Platform

• Windows x64
• Native local projects (not WSL)
• Exact Windows build was not collected

Summary

After the update, the native codex.exe process repeatedly hard-crashes when a local project is recognized as a Git repository. A controlled A/B test with two separate projects shows that the visibility of the .git directory deterministically changes the outcome:

• .git present: Codex crashes.
• .git renamed so Codex cannot detect it: Codex remains usable.
• .git restored: the crash returns.

This reproduced with either repository by itself, so it is not limited to multi-repository interaction.

Reproduction / controlled tests

1. Close Codex completely.
2. Open a local project that contains a .git directory.
3. Launch Codex and resume normal project use.
4. codex.exe exits with a native Windows crash.
5. Close Codex and rename .git to a non-Git name such as .git.codex-disabled.
6. Relaunch Codex and use the same project: the crashes stop.
7. Restore the directory name to .git: the crash returns.

This was tested independently on two local repositories.

Both repositories initially had zero commits, but that was ruled out as the direct cause:

• An empty initial commit was created in each repository.
• git rev-list --all --count returned 1 for each repository.
• git rev-parse --verify HEAD returned a valid commit hash for each repository.
• Codex still crashed with .git present.

Therefore this is not only an unborn-HEAD / zero-commit problem. The remaining common factors include Git repository detection/watching, Japanese (non-ASCII) project paths, and repositories with no tracked files beyond an empty initial commit.

Windows Error Reporting evidence

Repeated failures on 26.721.3996.0:

Faulting application: codex.exe
Faulting module: codex.exe
Exception code: 0xc0000409
Fault offset: 0x000000000d3e12f1
Fast-fail parameter (P10): 7

The same signature occurred repeatedly at approximately 15:44, 16:46, and 17:22 local time. Windows reported the same failure bucket hash for these events.

The earlier 26.721.3404.0 package also crashed with 0xc0000409, at fault offset 0x000000000d3ee081.

Relevant app-log observations

Before applying the workaround, the logs repeatedly showed Git repository watcher activity, including:

info [git-repo-watcher] Starting git repo watcher
warning [git] git.command.complete ... subcommand=rev-parse ... exitCode=128

The rev-parse failures were observed while the repositories still had unborn HEADs. Making both HEADs valid did not prevent the native crash, so those command failures are not the sole cause.

Expected behavior

Codex should not terminate the native process when detecting or watching a valid Git repository. Any watcher, path, encoding, or repository-state error should be isolated and surfaced gracefully.

Current workaround

Rename .git so Codex does not detect the project as a Git repository. This makes the app usable again, but disables Git-aware Codex features for those projects.

Possibly related issues

• #31989 — Windows codex.exe 0xc0000409 native crashes
• #34473 — Windows Git scanner retry loop triggered by an unresolvable .git path
• #27120 — Windows Desktop exits during background Git work

This report appears distinct because the crash is reproducibly toggled by hiding/restoring .git, persists after HEAD becomes valid, and reproduces with either repository independently.

Privacy / diagnostics

Project names, user name, and local paths have been sanitized. Windows WER generated minidumps on the affected machine; they can be provided through a private channel if maintainers request them.