Skip to content

[Critical][Windows Desktop 26.721.4979.0] runaway background Git loop exhausts system commit, crashes DWM, and forces reboot #35776

Open

Description

@TheWickie

Codex version

  • Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Desktop host: ChatGPT.exe 150.0.7871.128
  • Git for Windows: 2.50.1.windows.1

Platform

  • Windows 10 x64, build 19045
  • 32 GB physical RAM
  • 36 GB page file
  • Approximately 72.9 GB Windows commit limit

Severity / impact

Critical: whole-machine resource exhaustion requiring a forced reboot.

While Codex Desktop was left open after project work had completed, it entered a background Git status/diff/review loop. Windows exhausted virtual-memory commitment, git.exe began crashing continuously, unrelated applications failed, Desktop Window Manager crashed, and the machine became unusable. A forced reset was required.

This is more severe than sustained CPU usage: Windows explicitly reported low virtual memory and Git returned STATUS_COMMITMENT_LIMIT.

What happened

Codex Desktop was associated with a valid but data-heavy Git repository. The repository contained approximately:

  • 32,133 files under a generated/simulation-data directory
  • 9.58 GB under that directory
  • a Git index of approximately 434 KB

The app was not being actively used when the visible failure became severe. VS Code with the Codex extension was also open, but VS Code's built-in Git log reported zero discovered repositories and no continuing Git activity after its initial scan. Codex Desktop's own logs explicitly attribute the repeated commands to Desktop components.

Codex Desktop logged at least 348 Git command completions/failures during the session. Between approximately 13:10 and 13:22 local time it logged 257 Git operations, including:

  • 82 operations in one minute
  • 122 operations in the following minute

The logged callers/request kinds were primarily:

  • source=local_conversation_git_actions requestKind=review-summary
  • source=local_conversation_git_actions requestKind=status-summary
  • source=review_model requestKind=review-summary
  • source=review_model requestKind=branch-diff-stats
  • git-repo-watcher

Repeated commands included variants of:

git ... status --renames --porcelain=v1 -z --untracked-files=no
git ... status --no-renames --porcelain=v1 -z --untracked-files=normal
git ... ls-files -u -z
git ... diff --no-ext-diff --no-textconv ... --raw --numstat -z

Several diff attempts produced exactly 520,192 bytes of stdout before cancellation. Failed/cancelled operations were retried repeatedly.

Correlated Windows timeline

Local time:

  • 13:11 — Codex Desktop's repeated Git review/status work is already visible in its logs.
  • 13:14:36 — Windows Resource Exhaustion Detector: computer is low on virtual memory.
  • 13:15:14 — the exhaustion detector itself records a memory-allocation failure.
  • 13:15:27 — Microsoft-Windows-PerfProc can no longer collect process-performance information.
  • 13:15:58 — git.exe, ChatGPT.exe, Chrome, Steam web helper, and services begin crashing together.
  • 13:16:25 — another low-virtual-memory notification and detector allocation failure.
  • 13:18:01–13:18:02 — 40 git.exe Application Error events in approximately two seconds.
  • 13:20:21 — another low-virtual-memory notification and detector allocation failure.
  • 13:20–13:22 — Git crash/retry storm continues.
  • 13:22:05 — dwm.exe crashes.
  • 13:22:07 — bundled codex.exe crashes with 0xc0000409 at offset 0x000000000d3e12f1.
  • 13:25:39 — Windows still reports low virtual memory.
  • 14:55:27 — another remaining git.exe crash is recorded.
  • 14:57 — an unrelated desktop application hangs.
  • 14:58 — Kernel-Power Event 41 records the forced/unclean reboot.

Windows recorded 73 separate git.exe Application Error events during this incident.

Significant error codes

Codex Desktop's Git log recorded:

3221225773 = 0xC000012D = STATUS_COMMITMENT_LIMIT
3221225794 = 0xC0000142 = DLL initialization failed
3221225477 = 0xC0000005 = access violation

Windows Application Error events for Git additionally included:

  • 0xc00000fd — stack overflow
  • 0xc0000005 — access violation
  • 0x40000015 — fatal application exit

ChatGPT.exe, Chrome, and Steam's web helper failed with 0xe0000008 during the same exhaustion window.

Steps that may reproduce

  1. Use Codex Desktop on Windows with a valid, large/data-heavy Git repository.
  2. Allow a turn that causes local conversation review/status summaries and Git diff/status collection.
  3. Leave Codex Desktop open and idle after the visible turn completes.
  4. Observe the Desktop log under %LOCALAPPDATA%\Codex\Logs.
  5. Watch for repeated [git] git.command.complete records from review_model and local_conversation_git_actions, especially cancelled or failed status/diff calls.
  6. Observe system commit and git.exe process creation/crashes.

Because allowing the loop to continue rendered the machine unusable, intentionally reproducing it to completion is unsafe.

Expected behavior

  • Background Git inspection must be bounded, debounced, and cancelled after a turn/project becomes inactive.
  • Failed or cancelled Git status/diff operations must not be retried without backoff or a circuit breaker.
  • Git subprocess concurrency and retained output must have strict limits.
  • A repository scan must never be able to exhaust system commit or destabilize DWM and unrelated applications.
  • Codex should surface one actionable repository-status error and suspend background Git integration for the affected repository.

Working diagnosis

The evidence proves that Windows exhausted virtual-memory commitment and that Codex Desktop initiated hundreds of Git review/status operations immediately before and during the exhaustion.

It does not by itself prove a classic heap leak confined to ChatGPT.exe/codex.exe. The likely product defect is an unbounded retry/process-output lifecycle failure: failed or cancelled Git children and/or captured outputs are not released quickly enough while additional review/status jobs continue to be scheduled.

A private-bytes/process-creation ETW trace or maintainer diagnostic build would be required to distinguish retained Codex heap, unreaped child processes, and output-buffer retention.

Related issues

Privacy

User name, hostname, repository name, full paths, conversation content, account details, and raw logs are intentionally excluded. Sanitized event exports or narrowly scoped diagnostics can be provided through a maintainer-approved private channel.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Jul 28, 2026
  2. dark13b commented on Aug 14, 2026

    @dark13b

    Additional independent reproduction on the Codex Windows desktop app:

    After background Git/MCP activity, the UI became unresponsive. Windows then reported a low-virtual-memory condition, a helper process failed to start with 0xc000012d, and Codex exited with 0xc0000409. The Windows compositor also crashed, followed by a GPU watchdog reset. After restarting Windows, Codex became responsive again.

    This occurred during normal use and was not an intentional stress test. I am omitting hardware specifications, driver versions, usernames, paths, repository/project names, and raw logs for privacy. Sanitized diagnostics can be provided privately if needed.

    Please treat this as an additional confirmation of the background process/commit-exhaustion failure pattern and its ability to cascade into desktop and GPU instability.

  3. dark13b commented on Aug 14, 2026

    @dark13b

    Follow-up recurrence:

    After the app failed again and restarted, the ETABS MCP began repeatedly rejecting Codex resource-discovery requests (resources/list and resources/templates/list) because those handlers are unavailable. The errors repeated during startup/health checks.

    In this latest window, Windows did not record a new low-virtual-memory event or GPU watchdog event, so this appears to be an additional MCP protocol/startup failure that may contribute to app instability, separate from the earlier system-commit exhaustion cascade.

    No hardware details, user information, paths, project names, or raw logs are included.

  4. mySebbe commented on Aug 27, 2026

    @mySebbe

    Additional independent recurrence on a substantially newer Windows Desktop build, with a distinct caller path isolated.

    Environment:

    • Codex Desktop 26.820.7780.0 (Microsoft Store/MSIX)
    • Windows 10.0.26200.0 x64, build 26200.9168
    • Git for Windows 2.55.0.windows.5
    • 61.6 GiB physical RAM
    • Page file already active at 32,000 MiB initial / 64,000 MiB maximum

    This recurrence is explicitly attributed by Desktop logs to:

    requestKind=watch-repo
    source=composer_content
    subcommand=status
    

    Across 2026-08-26, the logs contain 34 records for that full untracked/ignored status path. 33 timed out at approximately 60 seconds, and every record has outputLimitMaxBytes=null. During the final retry window Windows reported insufficient virtual memory, stornvme could not allocate memory, Electron logged net::ERR_INSUFFICIENT_RESOURCES, and Windows emitted 140 git.exe “A new guard page for the stack cannot be created” popups in 41 seconds. Git then crashed with 0xc0000005, the desktop became unusable, and the machine required a forced power-off (Kernel-Power 41 / EventLog 6008, bugcheck 0).

    Earlier the same day there were another 302 matching Git guard-page popups and 18 Git Application Error events in one hour.

    The prior locally observed Desktop build 26.818.8289.0 last appears on 2026-08-25 at 21:20; 26.820.7780.0 first appears at 00:29 on 2026-08-26, before these incidents. This is strong regression correlation, although only internal source/build history can identify the responsible change.

    The focused report for the composer_content/watch-repo path is now available as #41091: #41091. It adds the exact current-build log signature, bounded reproduction, and the Windows event timeline while keeping prompts, account data, repository names, and private paths out of the public report.

  5. acer4322 commented on Sep 11, 2026

    @acer4322

    Additional recurrence on Codex Desktop 26.903.9818.0, observed on 2026-09-11, with process-table and private-memory evidence linking thousands of accumulating Git processes to one Codex backend. This appears closely related to this issue; the exact underlying defect has not been established.

    Environment

    • Microsoft Store package: OpenAI.Codex, version 26.903.9818.0
    • Windows 11 Home 25H2 x64, build 26200.9445
    • 32 GiB installed RAM (approximately 31.85 GiB usable)
    • Git for Windows 2.49.0.windows.1
    • System-managed page file already enabled; Windows expanded it during the incident.

    Observed escalation

    During ordinary Codex use, the computer became nearly unresponsive and the user observed Codex fail. This was not an intentional stress test. A local recorder captured system commit via GetPerformanceInfo and process identity, creation time, parent PID, and private bytes via Win32_Process.

    Times below are UTC+08:00 on 2026-09-11; sizes are GiB.

    Sample time Enumerated git.exe processes Git private bytes System commit / limit
    20:45:53 0 0 15.33 / 51.85
    20:48:55 824 15.00 33.04 / 51.85
    20:50:59 3,623 36.65 60.44 / 61.97
    20:53:55 9,977 49.87 84.73 / 85.23
    20:55:46 13,495 54.34 95.22 / 96.32

    In the final sample:

    • 13,492 Git processes could be traced through parent/child relationships to the same codex.exe backend: 10,450 direct children and 3,042 grandchildren. Parent creation times were checked to reject obvious PID-reuse mismatches.
    • Those Codex-linked Git processes accounted for 54.34 GiB private bytes.
    • The sample contained 13,818 distinct process IDs, with no duplicate PIDs.
    • The ten Codex desktop ChatGPT.exe processes totaled approximately 1.42 GiB private bytes; the codex.exe backend was approximately 0.36 GiB.
    • System paged pool was approximately 21.93 GiB. This is a separate system counter; I am not attributing every kernel allocation to Git.
    • The recorder itself used approximately 0.113 GiB private bytes.

    Windows and app evidence

    • 20:56:15: Windows reported critically low virtual memory and automatic page-file growth, warning that allocation requests could be refused.
    • 20:56:26: Software Protection service terminated with a paging-file-too-small error.
    • 20:56:28: git.exe crashed with exception 0xc00000fd.
    • 20:56:29: the PowerShell recorder also crashed; its last successful sample is therefore 20:55:46.

    During the same window, Codex desktop logs show repeated canceled Git operations with source=review_model, requestKind=review-summary, and status/diff subcommands for a local Git workspace. The process samples did not collect command lines, so these app-log records should not be interpreted as proof that every accumulated Git process was executing those particular commands.

    An earlier episode in the same monitoring session reached 20,094 enumerated Git processes, 20,092 linked to the same backend, before counts dropped again. The action responsible for that drop was not recorded.

    Limits and request

    There are 537 parseable samples before this final failure. Sampling targeted 10-second intervals but slowed to approximately 23 seconds under pressure. System counters and process enumeration are sequential, not atomic; counts can change while a sample is collected. The recorder stopped before the true peak or exact Codex-exit instant, and no Codex crash dump was analyzed. These observations establish large Codex-descended Git process/private-memory accumulation alongside system-wide exhaustion, rather than a proven heap leak in the desktop UI itself.

    Could maintainers investigate Git subprocess concurrency and cancellation/cleanup in the Windows backend, and advise whether a fixed build or supported mitigation exists? A bounded diagnostic that does not require reproducing full system exhaustion would be helpful.

    This public summary excludes account details, usernames, hostnames, repository/project names, private paths, prompts, and raw logs.

  6. Redstar1337 commented on Oct 1, 2026

    @Redstar1337

    I started getting this after the daemon bug showed up in the update from 1-2 weeks ago, it crashes my entire PC every 6 hours or so because of runaway GIT processes that hit the ceiling on commit memory and crashes OS.

    How is this not fixed yet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions