›_ Codex Issues
Codex Issues / #30926

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

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

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

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:

  • #16786 opened 2026-04-04, still open: repeated git.exe on Windows.
  • #17229 opened 2026-04-09, still open: Codex Windows App repeatedly starts git.exe.
  • #20567 opened 2026-05-01, still open: git.exe/conhost.exe remain after app close.
  • #29700 opened 2026-06-23, still open: memory leak / kernel memory symptoms.
  • #29729 opened 2026-06-23, closed as duplicate: stale git.exe process/token objects.
  • #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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 18 days ago

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

  • #30512
  • #29729
  • #29492
  • #29858
  • #30635

Powered by Codex Action

antonnevm-cloud · 18 days ago

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 · 18 days ago

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 · 18 days ago

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.

janijokinen · 7 days ago

I am seeing what appears to be the same issue on Windows 11.

In-app Codex feedback session ID:
019ee25c-ca99-7c93-b434-1997d09c7386

Environment:

  • Windows 11
  • 32 GB RAM
  • Codex Desktop
  • ChatGPT Classic also installed
  • F-Secure Endpoint Protection
  • F-Secure VPN tested with Hydra and WireGuard
  • OneDrive used for the main Codex project workspace

Observed behavior:

  • During extended Codex use, RAM usage rises toward 90–98%.
  • Task Manager does not show any single user-mode process consuming the memory.
  • RAMMap shows the retained memory at kernel level.
  • In bad state, I have observed:
  • Page Table approximately 8.5–9.9 GB
  • Nonpaged Pool approximately 2.7–3.1 GB
  • Paged Pool approximately 2.1–2.8 GB
  • Closing Codex does not reliably release the already accumulated kernel memory.
  • Reboot is required to recover.

Controlled observations:

  • ChatGPT Classic alone stayed stable.
  • Codex active with OneDrive closed still caused CommittedMB and kernel pools to grow.
  • OneDrive significantly worsened the growth, but was not the only trigger.
  • git.exe was not active during later growth tests, so Git is not the sole cause.
  • Earlier, broken empty .git folders in the OneDrive workspace caused repeated git.exe rev-parse / core.fsmonitor polling, but memory growth also occurs without git.exe running.

Example measurement with Codex active and OneDrive closed:

  • AvailableMB: 9657 -> 9474
  • PoolNonpagedMB: 1979.5 -> 1996.3
  • PoolPagedMB: 1893.4 -> 1923.7
  • CommittedMB: 25579.9 -> 25972.5
  • OneDriveWorkingMB: 0 throughout

Example measurement after stopping Codex / ChatGPT / OneDrive:

  • AvailableMB stabilized
  • CommittedMB stabilized
  • PoolNonpagedMB and PoolPagedMB stopped growing

This looks consistent with the issue described here: Codex appears to trigger Windows kernel memory / pool growth. In my case OneDrive and endpoint protection may amplify the issue, but Codex appears to be the repeatable trigger.

RonnieBalle · 4 days ago

Independent reproduction on two Windows PCs (desktop app and native PowerShell CLI)

I independently reproduced the same progressive whole-system slowdown on two different, high-end Windows computers. This is not ordinary CPU or RAM exhaustion: after Codex has run long goals for hours to days, mouse/keyboard input, window dragging, video playback, and Windows generally become increasingly stuttery. Closing task/UI windows does not restore responsiveness; a Windows Restart restores it immediately for another few hours.

Environment for the measured reproduction

  • Windows 11 x64
  • Codex desktop package: OpenAI.Codex_26.707.9981.0
  • Desktop-bundled Codex helper: 0.144.2
  • npm-installed Codex CLI: 0.144.4
  • Windows sandbox config: [windows] sandbox = "elevated"
  • Two long-running goals had been active for a little over one day
  • The qualitative failure also occurs when using Codex CLI from native PowerShell, not only through the desktop UI

Live measurements while Windows was severely degraded

The machine still had about 139 GB available RAM. Total CPU was only about 18–22%, with no meaningful processor queue, paging, disk, GPU, DPC, or thermal pressure.

Instead, the abnormal state was:

  • lsass.exe had roughly 82,000–90,000 handles and often consumed close to one logical CPU core.
  • LSASS handle samples while Codex activity was running:
  • 82,584 -> 82,669 in 30 seconds (+85)
  • 82,847 -> 83,002 in about 57 seconds (+155)
  • It later reached approximately 89,960 handles.
  • dwm.exe was consuming roughly 1.2–1.6 CPU cores, matching the visible whole-desktop/window-dragging stutter despite low GPU activity.
  • Short process snapshots repeatedly found 48–115 concurrent git.exe processes. At least one observed git.exe was directly parented by the desktop host process.
  • System-wide there were about 335,000 handles, with roughly 8.62 GB paged pool and 4.8 GB nonpaged pool.

After one of the two goals entered the paused state, Git concurrency fell to approximately 4–6 processes, and one LSASS sample changed from 89,971 -> 89,949 over 30 seconds. This suggests pausing/stopping the workload reduces new churn, but the accumulated Windows state does not materially recover.

Native Windows sandbox churn

A read-only count of one day's Codex Windows sandbox log showed approximately:

  • 10,784 sandbox starts
  • 10,754 setup refresh: spawning entries
  • 10,782 setup completions
  • 10,430 read-ACL setup runs
  • 348 failures
  • 357 “helper already running” messages

The log shows codex-windows-sandbox-setup.exe being spawned and ACL setup being applied for nearly every shell command. This is consistent with the process/security-token churn described in this issue.

Other observations

  • Microsoft Defender repeatedly requested submission/inspection of the small Codex config.toml, but temporarily disabling Defender as a diagnostic test had zero visible effect on the system lag. This makes Defender an unlikely primary cause in this reproduction.
  • Codex local state was unusually large after long use: about 132 GB total, including approximately 108.5 GB archived sessions and an 18.5 GB logging SQLite database. This may exacerbate Git/file/database polling, but it does not explain the LSASS/token behavior by itself.
  • Closing all visible windows/tasks did not restore the machine. A restart remains the only observed way to reclaim the accumulated state.
  • No arbitrary LSASS handles were closed and LSASS was not terminated.

Interpretation / request

This independently supports the mechanism in this issue: high-frequency Codex Git and native Windows sandbox process creation appears to cause sustained security-token/kernel-object retention, eventually overloading LSASS/DWM and degrading the entire desktop. It also overlaps with the kernel-pool evidence in #31212.

Please investigate:

  1. Throttling/caching desktop Git repository polling instead of spawning many short-lived git.exe processes.
  2. Reusing Windows sandbox initialization/helper state rather than spawning setup and reapplying ACLs for nearly every command.
  3. Correct cleanup of process trees, tokens, pipes, handles, and kernel references after commands/goals finish or pause.
  4. Native PowerShell CLI reproduction, since this is not limited to the desktop GUI.
  5. A supported diagnostic bundle and a mitigation that does not require rebooting Windows.

Related reports: #31212, #17229, #16374, #28855, #16786 and discussion #14758.

Raw session databases, source paths, repositories, and unredacted logs are intentionally not attached publicly. Sanitized samples or private diagnostics can be provided to OpenAI maintainers if requested.

RonnieBalle · 3 days ago

Controlled post-restart A/B: leak resumes after goals restart with invalid .git trigger removed

Following the earlier report, I ran this controlled sequence on native Windows:

  1. Restarted Windows, which reclaimed the accumulated state.
  2. LSASS fell from about 100,998 handles before restart to 1,986 afterward. Paged pool fell from 10.074 GB to 0.503 GB; nonpaged pool from 4.879 GB to 1.651 GB.
  3. Renamed two empty/invalid .git directories implicated by the minimal reproduction, and verified that neither original .git path existed.
  4. With the long-running goals stopped, LSASS remained around 1.9k and declined during short samples.
  5. Resumed two long-running Codex goals on native Windows.

A 46-second active measurement after resuming showed:

  • LSASS: 2,295 -> 2,416 (+121 end-to-end)
  • Sampled LSASS slope: +109 over 40.1 seconds, approximately +163 handles/minute
  • Concurrent git.exe: 15-24 throughout the interval
  • Distinct Git PIDs observed: 30
  • Paged pool: 0.681 -> 0.686 GB
  • Nonpaged pool: 1.720 -> 1.725 GB
  • Summed process handles: 167,898 -> 168,203
  • Both invalid .git paths remained absent

During the corresponding roughly two-minute sandbox-log interval, I counted:

  • 33 setup refresh: spawning events
  • 35 setup-completion events
  • 64 ACL-related lines
  • 32,723 bytes of log growth

Interpretation: an empty/invalid .git directory appears to be a real amplifier/minimal trigger, but it is not the root cause in this reproduction. Resuming native-Windows goals restored LSASS handle growth plus sustained Git and sandbox setup/ACL churn after that trigger was removed. This points toward a broader repeated process-creation / Windows sandbox setup / ACL or security-token cleanup problem.

No raw logs, private paths, repository source, or session content are attached.

RonnieBalle · 3 days ago

One-hour unattended measurement: sustained LSASS handle growth

I followed the short measurement with an uninterrupted one-hour test. The computer was left untouched, with only the same two native-Windows Codex goals running as active workloads.

To minimize observer effect, one persistent read-only PowerShell process sampled LSASS once per minute. No repeated Codex diagnostic commands were issued during the interval.

Measurement period: July 17, 2026, 11:59:50–12:59:50 CEST
Duration: 60.0153 minutes
Samples: 61

Results:

  • LSASS PID: 1980
  • Starting handles: 2,739
  • Ending handles: 5,145
  • Net accumulation: +2,406 handles
  • End-to-end average: +40.09 handles/minute
  • Least-squares regression slope: +40.35 handles/minute
  • Increasing one-minute intervals: 48
  • Decreasing intervals: 11
  • Unchanged intervals: 1
  • Minimum one-minute change: -35
  • Maximum one-minute change: +152

The regression slope closely matches the end-to-end average, demonstrating sustained growth rather than the result being caused by a single spike.

The previous 46-second measurement showed approximately +163 handles/minute during a burst of activity. This longer unattended measurement indicates that approximately +40 handles/minute is a more representative sustained rate under these two goals.

For additional context, the clean post-restart LSASS count was approximately 1,986 handles. It has now reached 5,145, an increase of 3,159 handles. If the measured hourly rate remained constant, reaching approximately 100,000 handles from the current state would take roughly 39 hours. This is an extrapolation, not a prediction, because workload intensity and cleanup activity vary.

No raw logs, private paths, repository source, or session content are attached.