Windows Codex app may leave large numbers of stale git.exe process/token objects

Summary

During a long-running Codex for Windows session involving repeated local Git and PowerShell operations, system RAM climbed above 30 GB on a 32 GB machine. Kernel pool analysis showed unusually high Proc and Toke allocations and a very large discrepancy between live processes and the Windows process-object performance counter.

This report is about a possible Codex child-process lifecycle issue or interaction with a Windows/security driver. The evidence shows correlation with Git-heavy Codex activity, but does not establish that Codex itself retained the kernel objects.

Environment

• Codex for Windows package path version: OpenAI.Codex_26.616.9593.0_x64
• Codex executable file/product version: 149.0.7827.115
• Windows 11 Pro 10.0.26200 (build 26200)
• RAM: 32 GB
• Local repository workflow
• Codex thread ID: 019ebe00-b51c-7fa1-ba7d-191289f7dbe6

Contact email, if further diagnostics are useful: todd10000@gmail.com

Workload before the incident

• A long-running Codex desktop thread, including overnight continuation.
• Many repository operations: git status, diff, fetch, commit, push, and validation checks.
• Many short-lived PowerShell commands launched through Codex.
• Repeated Excel COM regression tests and read-only web-service tests.
• No intentional process-spawning loop.
• GitHub CLI was not the Git binary used for most repository work; Codex's bundled Git runtime was used.

Observed behavior

• Total memory usage continuously rose above 30 GB.
• Task Manager showed roughly 4-5 GB Nonpaged Pool and over 2 GB Paged Pool.
• RAMMap/WPA showed approximately:
• Proc: 1.8-2.0 GB
• Toke: about 1.0 GB
• Nonpaged Pool: about 5 GB
• (Get-Process).Count remained around 180.
• Get-Counter '\Objects\Processes' reported about 551,745 process objects.
• Repeated samples were essentially flat: 551745, 551747, 551747, suggesting historical accumulation rather than rapid growth at that moment.
• Handle and live-process counts otherwise appeared normal.

A partial !process 0 0 WinDbg enumeration was stopped after about ten minutes. The partial image counts included:

git.exe       1060
conhost.exe    561
svchost.exe     93
Codex.exe        9
powershell.exe   5

These counts are only a partial sample, not a complete enumeration.

Other investigation

• wtd.sys / Web Threat Defense Service was stopped and disabled during diagnosis; the memory issue continued.
• WPA did not identify a single obvious third-party driver as the dominant CPU consumer.
• A complete memory dump could not be collected under memory pressure. A partial kernel stack dump was collected, but several WinDbg commands could not complete against it.
• No kernel drivers or services were installed or modified by Codex during the project work.

Recovery

A Windows reboot immediately restored normal memory usage:

• About 9 GB in use and 22 GB available after reboot.
• Subsequent sample: approximately 218 live processes, 634 process objects, 486 MB Nonpaged Pool.
• Nonpaged Pool remained stable over a short sample.

Expected behavior

Exited Git, PowerShell, console-host, and other child-process objects should be released without long-term growth in Proc/Toke kernel pool allocations.

Actual behavior

Hundreds of thousands of process objects appeared to remain referenced after the corresponding user-mode processes had exited, eventually consuming most physical memory.

Possible reproduction / monitoring

The issue has not yet been reliably reproduced after reboot. A useful monitoring setup while running a Git-heavy Codex session is:

(Get-Process).Count
(Get-Counter '\Objects\Processes').CounterSamples.CookedValue
(Get-Counter '\Memory\Pool Nonpaged Bytes').CounterSamples.CookedValue / 1MB

A recurrence would be indicated by the process-object counter climbing dramatically while the live process count remains relatively stable.

Privacy

No repository contents, credentials, customer data, employee data, or application logs are included in this public report. The original local investigation summary can be provided privately if OpenAI requests it.