Codex Desktop on Windows triggers kernel Token/Toke growth via repeated git.exe process creation

[antonnevm-cloud]

Windows Codex Desktop triggers kernel Token/Toke object growth via repeated git.exe process creation

Summary

On Windows 11, Codex Desktop appears to trigger sustained growth of Windows kernel Token objects / pool tag Toke.

The local ETW evidence points to the Codex Desktop GUI process repeatedly launching git.exe for repository/root detection. Closing Codex stops the Token object growth; reopening Codex starts it again.

This does not look like a normal Codex.exe user-space memory leak. The missing RAM is mostly kernel/system memory: Paged Pool, Nonpaged Pool, Page Table, and very high kernel object counts.

Environment

• OS: Windows 11 Pro, build 28000
• RAM: 63.38 GB
• Codex package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
• Codex executable/product version observed locally: 149.0.7827.197
• Git path used by Codex: C:\Program Files\Git\cmd\git.exe

High-level symptom

Task Manager/RAMMap showed high used RAM that was not attributable to normal user processes.

Local counters showed:

• Token objects around 1.25M to 1.29M
• Token handles only around 2.1K
• Paged Pool around 6.9 GB
• Nonpaged Pool around 2.55 GB
• User-mode Codex working set was much smaller than the missing RAM.

The Token objects vs Token handles mismatch suggests kernel-held references, not visible user handles.

Close/reopen confirmation

After closing Codex Desktop:

• Observation window: 2026-07-02T16:37:38 to 2026-07-02T16:52:39
• CodexProcesses=0 throughout
• Token objects: 1,289,018 -> 1,288,882
• Delta: -136 over 15 minutes

After reopening Codex Desktop:

• Observation window: 60 seconds
• CodexProcesses=9
• Token objects: 1,289,270 -> 1,289,550
• Delta: +280 in 60 seconds

ETW/WPR evidence

Two local WPR pool traces were captured and analyzed with TraceEvent.

First trace:

• Events read: 126,078,389
• Toke allocations: 42,299
• Toke frees: 41,848
• Net Toke count: 451
• Net Toke bytes: 812,544
• Largest outstanding Toke stack: first process Codex.exe, Count=420, Bytes=752,448

Second mostly-idle trace:

• Events read: 131,809,943
• Toke allocations: 36,605
• Toke frees: 36,415
• Net Toke count: 190
• Net Toke bytes: 355,200
• Largest outstanding Toke stack: first process Codex.exe, Count=272, Bytes=487,488

Symbolized kernel stack:

NtCreateUserProcess
PspAllocateProcess
PspInitializeProcessSecurity
SeSubProcessToken
SepDuplicateToken
ObCreateObjectEx
ObpAllocateObject
ExAllocatePoolWithTag

This is the Windows process creation / security token duplication path.

Process-start evidence

The second trace contained 1,264 process start events.

Largest direct parent group:

• Parent: Codex.exe, PID 18932
• Child: git.exe
• Count: 263 starts in approximately 54.6 seconds

Command-line grouping:

• 225 starts:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

• 38 starts:

"C:\Program Files\Git\cmd\git.exe" config --null --get core.fsmonitor

Additional direct child starts from Codex.exe:

• powershell.exe: 55 starts, mostly process inventory via Get-CimInstance Win32_Process

Local app inspection

Read-only inspection of the installed app.asar showed code paths using:

• gitManager.getWorktreeRepository(...)
• git rev-parse --show-toplevel
• core.fsmonitor

I did not find a user-facing setting in this build to disable the Git polling / review Git query behavior.

Expected behavior

Codex Desktop should not create hundreds of git.exe child processes per minute for stable workspace root detection, and should not cause unreclaimable Windows kernel Token/Toke object growth during long-running sessions.

Actual behavior

Codex Desktop repeatedly launches git.exe from the GUI process. On this system, that process churn correlates with Token/Toke growth in the Windows kernel. Closing Codex stops new growth; reopening Codex resumes growth.

Related public issues

• Codex Windows App keeps spawning git.exe status --porcelain=v1 -z and leaves orphan git.exe / conhost.exe processes #17229
• Memory leak #29700
• Windows Codex app may leave large numbers of stale git.exe process/token objects #29729
• Codex Desktop memory leak / Windows kernel memory retention #30389

Privacy / attachments

I have local ETW traces and CSV summaries, but the raw ETL files are very large and may contain local paths/process details. I would prefer not to attach full logs or ETL files publicly. I can provide sanitized summaries or share raw traces privately if requested by OpenAI maintainers.

---

Additional issue-age context checked on 2026-07-02

Related Windows Git/process and memory-retention reports are not isolated:

• Windows app repeatedly spawns \git ls-files --others --exclude-standard -z; ntfs.sys NtFC nonpaged pool grows continuously #16786 opened 2026-04-04, still open: repeated git.exe on Windows.
• Codex Windows App keeps spawning git.exe status --porcelain=v1 -z and leaves orphan git.exe / conhost.exe processes #17229 opened 2026-04-09, still open: Codex Windows App repeatedly starts git.exe.
• Codex Windows App keeps spawning about 1000 git command per minute NON STOP #20567 opened 2026-05-01, still open: git.exe/conhost.exe remain after app close.
• Memory leak #29700 opened 2026-06-23, still open: memory leak / kernel memory symptoms.
• Windows Codex app may leave large numbers of stale git.exe process/token objects #29729 opened 2026-06-23, closed as duplicate: stale git.exe process/token objects.
• Codex Desktop memory leak / Windows kernel memory retention #30389 opened 2026-06-28, closed as completed: Windows kernel memory retention.

The current local evidence adds ETW/WPR stack-level data and close/reopen token-object deltas.

[github-actions]

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

• Windows VS Code extension repeatedly spawns git.exe in non-Git folders, causing ~10 GB paged-pool growth #30512
• Windows Codex app may leave large numbers of stale git.exe process/token objects #29729
• Windows Codex desktop app creates an empty .git folder, then spawns git process repetitively #29492
• Windows: Opening Codex tab in non-Git workspace causes continuous git.exe spawning and high Defender CPU #29858
• Codex app-server spins on repeated git rev-parse when workspace has invalid empty .git directory #30635

Powered by Codex Action

[antonnevm-cloud]

Post-reboot update: I found a much more specific local trigger.

After a fresh Windows reboot, the active Codex workspace contained an empty .git directory. It was not a valid Git repository:

.git entry count: 0
git -C . rev-parse --show-toplevel
fatal: not a git repository (or any of the parent directories): .git
exit code: 128

Even though this .git was invalid, Codex.exe repeatedly launched:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

10-minute measurement before removing the empty .git trigger:

• Window: 606 seconds
• Token objects: 9,937 -> 24,321
• Delta: +14,384, about +1,424/min
• Paged Pool: 0.763 GB -> 0.823 GB
• Nonpaged Pool: 0.642 GB -> 0.659 GB
• git.exe processes were present and parented by Codex.exe

I then renamed the empty .git directory out of the workspace path, without deleting it.

10-minute measurement after removing the empty .git trigger:

• Window: 601 seconds
• Token objects: 26,734 -> 27,112
• Delta: +378, about +37.7/min
• Token handles: 1,597 -> 1,597
• git.exe processes: 0 -> 0

So the strongest minimal repro candidate is:

1. On Windows, open Codex Desktop on a folder containing an empty .git directory, not a valid Git repo.
2. Leave Codex idle.
3. Observe repeated git.exe rev-parse --show-toplevel calls from Codex.exe.
4. Observe rapid Windows kernel Token object growth.
5. Rename/remove the empty .git directory and observe that repeated git.exe calls stop and Token growth drops sharply.

This points specifically to invalid/empty .git handling causing a repeated Git probing loop, rather than normal Git repo activity.

[antonnevm-cloud]

Follow-up valid Git repo test:

I tested whether the same git.exe churn reproduces with a valid Git repository and clean status. It did not reproduce the massive loop seen with an empty/invalid .git.

Setup:

• Same active Codex Desktop workspace.
• Temporary valid .git created with git init.
• git rev-parse --show-toplevel succeeded.
• git rev-parse --is-inside-work-tree returned true.
• git status --porcelain=v1 -z was empty before and after the measurement.
• Existing workspace files were excluded through .git/info/exclude so the repo status stayed clean.

10-minute measurement:

• Window: 602 seconds
• Samples: 121, every 5 seconds
• Token objects: 27,333 -> 28,404
• Delta: +1,071, about +106.7/min
• Token handles: 1,660 -> 1,656
• git.exe processes: 0 -> 0
• Max sampled git.exe process count: 2
• Samples with git.exe > 0: 1 / 121
• Paged Pool: 1.130 GB -> 1.171 GB
• Nonpaged Pool: 0.970 GB -> 0.997 GB

Comparison:

• Empty/invalid .git: +14,384 Token objects in 606 seconds, about +1,424/min, repeated git.exe rev-parse --show-toplevel.
• Valid Git repo with clean status: +1,071 Token objects in 602 seconds, about +106.7/min, git.exe observed in only one sampled interval.

Limitations:

• This was done in the active Codex workspace rather than a brand-new separate small folder.
• Windows process-start event subscription via CIM/WMI was denied for the current non-elevated process, so this used 5-second polling plus Token object deltas.

Conclusion: the rapid git.exe probing loop appears specific to empty/invalid .git handling. A valid Git repository with clean status did not reproduce the same churn in this test.

[antonnevm-cloud]

Additional minimal workspace repro requested through OpenAI Support case 10865001.

Git version/source

• git --version: git version 2.54.0.windows.1
• Git executable used by the repeated probes: C:\Program Files\Git\cmd\git.exe
• This is system Git for Windows, not a Codex-bundled Git.

Observed repeated commands:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
"C:\Program Files\Git\cmd\git.exe" config --null --get core.fsmonitor

Minimal projectless Codex workspace repro

I attempted to pre-create an empty folder with an empty .git and open that exact folder through a Codex projectless thread. The available thread API created a fresh workspace with a -2 suffix instead, so I could not force the exact pre-existing-folder-open sequence through that API.

I then tested in that brand-new projectless Codex workspace by creating an empty .git while the workspace was open in Codex. The workspace was otherwise empty except for Codex's outputs directory.

Setup:

• Empty .git entry count: 0
• git rev-parse --show-toplevel: fatal: not a git repository, exit code 128

Phase A, empty .git present while Codex was open:

• Window: 2026-07-02 20:09:12 to 2026-07-02 20:19:53 local time, 641 seconds
• Samples: 271
• Token objects: 30,592 -> 46,559
• Delta: +15,967, about +1,494.57/min
• Token handles: 1,684 -> 1,685
• git.exe processes: 2 -> 2
• Max sampled git.exe process count: 4
• Samples with git.exe > 0: 244 / 271, 90.04%
• Paged Pool: 1.540 GB -> 1.685 GB, delta +0.145 GB
• Nonpaged Pool: 1.414 GB -> 1.461 GB, delta +0.047 GB

Remove .git while Codex remains open

I renamed/removed .git from the workspace path while Codex was still open and did not restart Codex before the next measurement.

Phase B, after renaming/removing the empty .git, no Codex restart:

• Window: 2026-07-02 20:21:16 to 2026-07-02 20:31:56 local time, 640 seconds
• Samples: 121
• Token objects: 47,660 -> 47,561
• Delta: -99, about -9.28/min
• Token handles: 1,696 -> 1,683
• git.exe processes: 0 -> 0
• Max sampled git.exe process count: 0
• Samples with git.exe > 0: 0
• Paged Pool: 1.743 GB -> 1.770 GB, delta +0.027 GB
• Nonpaged Pool: 1.492 GB -> 1.496 GB, delta +0.004 GB

Conclusion: the empty/invalid .git trigger reproduces strongly in a minimal projectless Codex workspace. Removing/renaming the empty .git while Codex remains open stops the git.exe loop and Token object growth without requiring a Codex restart. This lines up with the earlier valid-repo test: a valid clean Git repo did not reproduce the massive git.exe loop.