›_ Codex Issues
Codex Issues / #35179

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

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

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34907
  • #33936

Powered by Codex Action

cocoichisan · 1 month ago

Correction / additional observations

The original report overstated the .git rename as a complete workaround. Further testing showed:

  • Both test repositories were given valid initial commits (rev-list --all --count = 1; rev-parse --verify HEAD succeeded), but Desktop still crashed.
  • Each repository could trigger the crash independently, so the issue is not limited to unborn HEADs or multi-repository interaction.
  • Hiding .git changed the behavior during the initial A/B tests, but it did not prove a complete or durable workaround; a later crash still occurred during continued use. Please treat .git visibility as a correlated trigger observed in the early tests, not as a confirmed root cause or guaranteed workaround.
  • The project-specific workload may also contribute. The strongest confirmed evidence remains repeated native codex.exe 0xc0000409 failures after the 26.721 update.

A separate CLI failure with an explicit large allocation error has now been filed as #35274. That CLI issue is reported separately because its failure signature differs, and no common root cause is claimed.

onodanaoto-main · 1 month ago

I am seeing a potentially related regression in a Remote SSH setup. I am adding sanitized observations because they may help distinguish the Windows Desktop crash from the remote CLI/app-server process.

Environment

  • Two separate Windows x64 PCs, anonymized here as PC-A and PC-B
  • Both use Codex Windows Desktop and connect to the same Ubuntu Linux server through Codex Remote SSH
  • Actual tool execution runs through Codex CLI/app-server on the Linux server
  • Remote CLI version: 0.145.0-alpha.4
  • The remote workspace is a Git repository with many Japanese/non-ASCII directory names
  • The unexpected Desktop exits started around July 24-25, 2026
  • Windows Desktop package versions and Windows exception codes have not yet been collected

Behavior

  • The Windows Codex window closes without warning.
  • It tends to happen shortly after submitting a prompt or while typing.
  • It generally remains open while idle.
  • The same symptom has occurred on both Windows PCs.
  • Restarting Desktop reconnects to the remote server.
  • The Linux codex app-server remains alive; no OOM kill, disk exhaustion, or server-side app-server crash was observed.
  • Work running through the remote CLI is generally preserved, but repeated Desktop restarts interrupt the workflow.

Server-side evidence

For PC-A, Tailscale SSH logged the Desktop proxy session ending with context canceled at:

  • 2026-07-26 19:13:00 JST
  • 2026-07-26 19:14:54 JST
  • 2026-07-26 19:18:25 JST

Each exit was followed by a new Codex Remote SSH connection. The persistent remote app-server process did not restart.

The remote app-server log also contained:

Error: app-server control socket is already in use at ~/.codex/app-server-control/app-server-control.sock

This overlaps with the Remote SSH reconnect symptoms described in #23919.

Additional workspace condition

The workspace root directory was renamed recently. Some older threads still retain the previous, now-missing working directory and remote tool launches from those threads can return:

CreateProcess ... No such file or directory (os error 2)

However, the Windows Desktop application exits have been observed from two different PCs, so this does not appear to be a single-machine hardware issue.

I have not renamed or hidden .git because this is a production workspace and Git-aware behavior is required. I can provide sanitized server logs and Windows Reliability Monitor details after collecting the Desktop package version and exception code.

cocoichisan · 1 month ago

Stronger thread-specific finding

Further use narrowed the Desktop crash substantially.

  • The affected local thread attempted to process/package 100 PNG files in one task.
  • Opening that specific thread caused one codex.exe process to grow to approximately 17.2 GB in Windows Task Manager, while total system memory reached 97%.
  • The machine remained stable after terminating Codex and avoiding that thread.
  • Since the affected thread has no longer been opened, the repeated Desktop crashes have stopped.

The local thread ID is intentionally redacted from this public report.

This makes the current leading hypothesis excessive memory use while restoring/hydrating a large image-heavy thread, rather than Git repository detection being the primary cause. The earlier .git observations should be treated only as an initial correlation.

This is observational evidence from one affected thread, not yet a controlled reproduction on a newly created thread. The related CLI allocation failure remains tracked separately in #35274.