[Windows Desktop 26.820.7780.0] composer_content full-status retries exhaust system commit and hard-freeze Windows

What version of the Codex App are you using (From “About Codex” dialog)?

Microsoft Store/MSIX OpenAI.Codex 26.820.7780.0.

An update to 26.820.9563.0 was staged only after the last incident. It was not the running build during the failures and has not yet been tested.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Additional environment details:

• Windows 25H2, build 26200.9168
• 61.6 GiB physical RAM
• Page file: 32,000 MiB initial / 64,000 MiB maximum (active before the latest failure)
• Git for Windows 2.55.0.windows.5
• Codex CLI 0.147.0
• Native Windows workspace on a local NVMe volume, not WSL

What issue are you seeing?

Codex Desktop repeatedly schedules a full untracked/ignored git status through the composer_content / watch-repo path. Failed or timed-out scans are retried without an effective circuit breaker. On this machine the retry path exhausted Windows system commit, caused a large git.exe crash-dialog storm, made unrelated OS components unable to allocate memory, and hard-froze the machine until a forced power-off was required.

The relevant sanitized command shape is:

git -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor= \
  status --no-renames --ignored=matching --untracked-files=all \
  --porcelain=v1 -z -- <large-data-subtree>

The Codex log records identify the caller unambiguously:

requestKind=watch-repo
source=composer_content
subcommand=status
outputLimitExceeded=false
outputLimitMaxBytes=null

Across the affected day, the Desktop logs contain 34 git.command.complete records for this exact composer_content status path:

• 33 timed out, normally after approximately 60 seconds
• 1 failed with exit code 128 during the final resource-exhaustion window
• all 34 show outputLimitMaxBytes=null

Representative records from the final incident:

2026-08-26T18:50:02.954Z
durationMs=3678 exitCode=128 failureReason=nonzero_exit
requestKind=watch-repo source=composer_content
stderrBytes=707 stdoutBytes=0 subcommand=status timedOut=false

2026-08-26T18:51:20.649Z
durationMs=62901 exitCode=null failureReason=timed_out
requestKind=watch-repo source=composer_content
stderrBytes=0 stdoutBytes=0 subcommand=status timedOut=true

Correlated Windows timeline (local time, UTC+2):

• 20:50:01 — Windows reports insufficient virtual memory.
• 20:50:02 — the first Codex watch-repo status returns exit 128.
• 20:50:32 — stornvme reports that memory could not be allocated.
• 20:50:39 — Codex/Electron logs net::ERR_INSUFFICIENT_RESOURCES.
• 20:50:45–20:51:26 — Windows records 140 git.exe system-error popups: “A new guard page for the stack cannot be created.”
• 20:51:20 — the next Codex status attempt reaches a 62.9-second timeout.
• 20:54:12 — Windows records a git.exe crash with exception 0xc0000005.
• 21:09:54 — the machine is forcibly powered off after remaining unusable.
• Next boot — Kernel-Power 41 / EventLog 6008 records the unexpected shutdown, with bugcheck code 0.

This was not an isolated Git dialog. Earlier the same day Windows also recorded 302 matching Git guard-page popups, three low-virtual-memory popups, and 18 git.exe Application Error events in one hour.

No WHEA hardware error, disk-health failure, or bluescreen was recorded. Both NVMe drives report healthy. The storage warning was specifically an allocation failure during the commit-exhaustion window.

What steps can reproduce the bug?

Because reproducing the final system crash is unsafe, these are bounded reproduction steps:

1. On Windows, open a large valid Git repository containing a data-heavy subtree with many visible untracked/ignored paths. Some unreadable cache directories amplify the scan but are not required for the product-side retry defect.
2. Open or interact with a local Codex conversation so the composer starts repository watching.
3. Observe Desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs.
4. Look for git.command.complete records with requestKind=watch-repo source=composer_content and the full-status command above.
5. If one scan reaches the approximately 60-second timeout, stop the test. Do not allow repeated retries to continue to resource exhaustion.

Control observations:

• Git itself is otherwise usable manually in the same repository.
• After enabling Git's standard untracked/filesystem/index caches, the same full-status command with output discarded completed with exit code 0 in 3.754 seconds.
• A local safety guard that enforces one logical Codex full-status process tree at a time, lowers its priority, and terminates it at 50 seconds has prevented further Git/resource failures. This is a mitigation, not an upstream fix.
• Merely enlarging the page file did not prevent recurrence: the latest failure happened after the 32/64 GiB page-file setting was active.

Session IDs, prompts, usernames, repository names, private paths, and raw logs are intentionally omitted. Sanitized excerpts can be provided through a maintainer-approved private channel.

What is the expected behavior?

• composer_content repository watching must be single-flight per repository.
• A timeout, exit 128, spawn failure, or Windows resource error must open a circuit breaker instead of scheduling another full scan.
• Captured stdout/stderr and untracked-path enumeration must have hard size/resource limits; this path should not run with outputLimitMaxBytes=null.
• Timeout/cancellation must terminate and reap the complete Git for Windows process tree.
• Codex should surface one actionable repository-status warning and suspend automatic full scanning until the user retries.
• A repository scan must never be able to exhaust system commit or destabilize unrelated Windows components.

Additional information

This appears to be a regression correlated with Desktop 26.820.7780.0:

• The previous locally observed build, 26.818.8289.0, last appears in logs on 2026-08-25 at 21:20 local time.
• 26.820.7780.0 first appears on 2026-08-26 at 00:29.
• The virtual-memory/Git crash incidents and unexpected shutdowns occurred after that transition.

This timing is correlation, not proof of the responsible source commit. OpenAI would need internal build/source history to confirm the regression point.

Related reports describe the same broader failure family, but none found in search names the source=composer_content requestKind=watch-repo path:

• #35776 — whole-machine commit exhaustion from background Git activity
• #29408 — repeated/stuck Git polling processes on Windows
• #30820 — eager review_model / review-summary snapshots
• #37796 — git.exe crashes and orphaned children on Windows
• #38062 — Git timeout/cancellation retry behavior and missing emergency control

The distinct contribution of this report is the current 26.820.7780.0 reproduction, the composer_content/watch-repo source attribution, 33 repeated 60-second timeouts with no output limit, and the directly correlated Windows allocation-failure timeline.