Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   extensionIssues related to the VS Code extensionIssues related to the VS Code extension

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Jul 28, 2026
2. github-actions commented on Jul 28, 2026

   

   github-actionsBot

   on Jul 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][26.715.10079.0] Opening Codex spawns rapid Git/PowerShell churn and drives WMI + Defender CPU to ~60% #34854
   • Windows desktop app spawns many conhost.exe/taskkill.exe processes and can saturate disk #34548
   • Codex app is continuously spawning git.exe processes #34672

   Powered by Codex Action
3. tmesias commented on Jul 28, 2026

   

   tmesias

   on Jul 28, 2026

   Author

   More actions

   019f7a38-8dd7-7982-a88a-e4423a600445
4. cxclrfx commented on Aug 14, 2026

   

   cxclrfx

   on Aug 14, 2026

   More actions

   @tmesias — current Codex Desktop reproduction adds a strong Desktop-side coordinate to #35775

   I reproduced the same Git-origin/process-storm family you documented in #35775, but on the current Microsoft Store Codex/ChatGPT Desktop application rather than the VS Code extension. The capture is long enough, and the parent/child topology is clean enough, that I think it adds a useful coordinate for narrowing the remaining root cause rather than simply adding another “Windows is slow” report.

   This also intersects the Desktop work already reported in #29949, #26812, #34260, and #35880. I am writing this here because your requestKind=git-origins / source=sidebar_workspace_task_groups_task_dirs finding is the closest published coordinate I have seen to the behavior in this capture.

   Environment

   Observed on:

   • Windows x64, build 26200
   • Codex/ChatGPT Desktop package: OpenAI.Codex_26.810.4967.0_x64
   • Intel Core i5-14400F, 10 cores / 16 logical processors
   • 64 GB RAM
   • NVIDIA RTX 5060 Ti
   • normal local Git repository workspace
   • Git for Windows with Git Credential Manager
   • repository has a ChatGPT Sites remote, redacted here as:
     https://git.chatgpt-team.site/<workspace>/<project>.git

   The system was not memory constrained and the SSD was healthy. The user-visible symptom was system-wide cursor/UI stutter while Codex Desktop was active.

   40-minute process trace

   I ran a read-only 40.01-minute Windows process/performance capture while Codex Desktop was being used normally for local repository work.

   System summary:

   • 1,349 system samples
   • average total CPU: 27.21%
   • maximum total CPU: 84%
   • maximum processor queue: 18
   • maximum DPC CPU: 5%
   • maximum interrupt CPU: 1%
   • nonpaged pool: 1,167.4–1,191.2 MB
   • paged pool: 2,703.7–3,003.4 MB

   The important point is that this was not a classic sustained DPC/ISR storm or a RAM exhaustion event. The dominant abnormality was process churn.

   Process starts in 40 minutes:

   • conhost.exe: 5,832
   • git.exe: 5,535
   • reg.exe: 3,221
   • node.exe: 289
   • pwsh.exe: 135
   • dllhost.exe: 135
   • tzutil.exe: 72
   • workerd.exe: 68
   • taskkill.exe: 54
   • gh.exe: 24
   • rg.exe: 22
   • cmd.exe: 19
   • codex-windows-sandbox-setup.exe: 13
   • git-remote-https.exe: 6
   • git-credential-manager.exe: 6
   • sh.exe: 6

   Total process starts captured by the event trace: 15,563.

   That is approximately 389 process starts/minute averaged over the whole run, or about 6.5 process creations/sec continuously averaged over 40 minutes.

   The average hides much larger bursts.

   Peak minute

   At 23:30, the trace recorded:

   • 1,723 total process starts
   • 1,038 git.exe
   • 589 conhost.exe

   Peak second

   At 23:30:27, one single second contained 179 process starts:

   • 108 git.exe
   • 60 conhost.exe
   • 8 reg.exe
   • 1 pwsh.exe
   • 1 taskkill.exe
   • 1 svchost.exe

   This is the point I would treat as the strongest process-scheduling “vibration”: the failure is not merely an aggressive periodic poll. At peak, many repository/process discovery operations are alive in parallel within one scheduler interval.

   Parent topology: the Desktop main process is a primary source

   The current app is packaged under OpenAI.Codex_26.810.4967.0.

   The root Desktop process in the capture was:

   ChatGPT.exe, PID 13856

   The bundled app-server was a child:

   ChatGPT.exe (13856)
-> codex.exe app-server

   Over the 40-minute trace, PID 13856 directly created 5,832 children.

   Direct children of the Desktop main PID:

   • reg.exe: 3,221
   • git.exe: 2,530
   • taskkill.exe: 54
   • gh.exe: 24
   • cmd.exe: 2
   • node.exe: 1

   This matters because it narrows the origin of a large part of the storm to Desktop-shell/runtime behavior rather than the codex.exe app-server alone.

   There are additional Git descendants below those direct children, which explains why total git.exe count reaches 5,535.

   My strongest current hypothesis is therefore not “Git itself is slow.” It is that a Desktop-side state-refresh / metadata-discovery scheduler is producing redundant concurrent work, and the Windows subprocess model amplifies that work into system-wide latency.

   A second coordinate that may be under-investigated: reg.exe

   The git.exe / conhost.exe storm is already known. The new coordinate I would look at closely is the reg.exe volume:

   3,221 reg.exe starts in 40 minutes.

   All 3,221 were direct children of the Desktop main ChatGPT.exe PID in this capture.

   That is too regular to dismiss as unrelated system noise.

   I do not yet have the short-lived reg.exe command lines because the process-start ETW/WMI trace captured parent/PID/name, while command-line polling was too slow for sub-second children. I would specifically capture these command lines and the Desktop JS call site.

   If you inspect the packaged runtime, I would search for:

   • reg.exe
   • registry/tool discovery wrappers
   • Git/GitHub CLI discovery
   • App Paths / executable lookup
   • environment or shell capability refresh
   • code paths that repeatedly re-check installed tools or registry state after workspace/chat/process updates

   If the same refresh generation invokes both Git-origin discovery and registry/tool discovery, this could explain why the storm remains expensive even when only part of the Git path is suppressed.

   ChatGPT Sites / Credential Manager is a real but separate branch

   This repository has a local remote equivalent to:

   sites -> https://git.chatgpt-team.site/<redacted>/<redacted>.git

   and Git uses Credential Manager.

   During the same 40-minute capture I observed six complete remote-authentication helper chains.

   Representative chain:

   ChatGPT.exe
-> git.exe
-> git.exe
-> git-remote-https.exe
-> sh.exe
-> git.exe
-> git-credential-manager.exe

   The six GCM starts occurred approximately:

   • +16.8 s
   • +26.0 s
   • +53.1 s
   • +8 min 40.5 s
   • +10 min 40.3 s
   • +10 min 49.7 s

   after diagnostic start.

   This is consistent with #35880: background repository metadata discovery reaches a Sites HTTPS remote and invokes GCM even though the user did not request a fetch/pull/push operation.

   I would keep this logically separate from the main 5,535-Git storm:

   • local Git-origin/repository probing explains thousands of process starts;
   • remote metadata discovery against a Sites remote explains the smaller number of git-remote-https / GCM chains and the visible credential prompt.

   Fixing the GCM prompt alone will not fix the process storm.

   Conversely, suppressing broad Git-origin probing may also eliminate the conditions that invoke GCM.

   Important distinction from the empty-.git case

   This capture is from a real Git repository, not only an invalid/empty .git placeholder.

   So negative-caching invalid repositories is necessary for the empty-.git failure mode, but it is not sufficient for the general storm.

   The current behavior also needs to be bounded for valid repositories and historical task/workspace directories.

   That makes your #35775 coordinate particularly important:

   requestKind=git-origins
source=sidebar_workspace_task_groups_task_dirs

   The question I would now answer is:

   What invalidates that request, and how many logically equivalent requests can coexist before the prior one completes?

   Where I would instrument next

   Rather than instrumenting Git itself, I would instrument the caller immediately above the worker/request boundary.

   For every git-origins request, log only diagnostic metadata such as:

   • request generation/id
   • request source
   • invalidation reason
   • time since prior request
   • number of task directories supplied
   • number of canonicalized unique paths
   • number of unique Git common dirs
   • number of requests already in flight
   • cache hit/miss
   • negative-cache hit/miss
   • number of superseded requests cancelled
   • start/end duration
   • number of Git subprocesses spawned by that request

   Then compare that with process creation.

   If 100+ git.exe processes appear inside one second, I would expect to find one of these two shapes:

   1. one request fans out over a large, insufficiently deduplicated directory set; or
   2. several equivalent refresh generations overlap and each performs the same fan-out.

   The second case would explain the very sharp burst shape better than a simple timer.

   Specific runtime areas worth checking

   The earlier #29949 investigation identified a packaged Git worker handling git-origins, plus separate WMI/process-discovery paths. In a newer build the minified filenames may have changed, so I would locate them by stable strings rather than by old minified export names.

   Search the current app.asar / .vite/build payload for:

   • "git-origins"
   • "sidebar_workspace_task_groups_task_dirs"
   • Git-origin worker request handlers
   • rev-parse --show-toplevel
   • rev-parse --git-common-dir
   • config --get remote.origin.url
   • config --null --get core.fsmonitor
   • for-each-ref
   • remote show
   • reg.exe
   • taskkill.exe
   • Win32_Process
   • Win32_PerfFormattedData_PerfProc_Process

   I would then map:

   sidebar / thread / workspace invalidation
-> task-directory collection
-> canonicalization
-> git-origins request
-> worker fan-out
-> Git subprocess spawn

   and separately:

   command/process lifecycle
-> process/registry discovery
-> reg.exe / PowerShell / taskkill

   The key is to identify whether these are independent periodic systems or whether one UI/workspace state mutation causes multiple discovery subsystems to refresh together.

   Canonicalization boundary

   For Git-origin discovery, deduplication should happen on repository identity, not only the raw task-directory string.

   I would test canonicalization across:

   • path case differences on Windows
   • slash/backslash variants
   • task directories inside the same repository
   • Git worktrees sharing one common dir
   • historical thread cwd values
   • stale/missing task directories
   • nested directories inside one repository
   • duplicate workspace/thread references

   A list containing 100 historical task directories should not produce 100 independent full Git-discovery sequences when most resolve to the same small set of repositories.

   Possible stable cache key:

   canonical Git common-dir + relevant config mtime/generation

   rather than:

   raw task cwd

   Single-flight / cancellation boundary

   The next concrete intervention I would test is:

   • one in-flight git-origins calculation per canonical repository set/generation;
   • coalesce identical requests;
   • cancel or ignore superseded generations;
   • bounded worker concurrency;
   • cache positive origin results;
   • negative-cache invalid/missing/non-Git paths;
   • no immediate retry loop for unchanged failure state.

   The acceptance metric should be process creation proportional to unique repositories whose state actually changed, not proportional to sidebar refresh count, historical task count, or command lifecycle count.

   Remote default-branch / Sites rule

   Background UI metadata must not require network authentication.

   For a sites / sites-origin HTTPS remote, ordinary sidebar/chat refresh should not invoke a networked git remote show.

   If local metadata cannot establish the remote default branch, returning “unknown/not cached” is preferable to:

   background UI refresh -> remote HTTPS -> GCM

   The background path should use local Git config/refs only. A network operation should require an explicit user/agent action or an explicitly designed remote-refresh path.

   A focused regression invariant would be:

   Sending a normal chat message in a workspace containing a ChatGPT Sites remote must produce zero git-remote-https.exe and zero git-credential-manager.exe children unless a remote Git operation was explicitly requested.

   taskkill.exe may be a feedback amplifier

   This capture saw 54 taskkill.exe starts, all direct children of the Desktop main process.

   That is not the dominant storm in this machine, but given #34260 I would check whether subprocess churn causes repeated cleanup work and whether slow cleanup then creates a secondary feedback loop.

   For the cleanup boundary:

   • timeout every helper;
   • deduplicate cleanup for the same execution/PID tree;
   • global small concurrency cap;
   • backoff/circuit breaker when WMI/process enumeration is unhealthy;
   • prefer app-owned process tracking / Job Objects over repeated global process-tree discovery.

   Controlled intervention matrix

   To avoid conflating multiple Windows failure modes, I would run four isolated A/B interventions on the current build.

   A — Git-origin scheduling only

   Keep all other behavior unchanged.

   Change only:

   • canonicalize/dedupe repository roots;
   • single-flight;
   • cache;
   • bounded concurrency;
   • cancellation of superseded refreshes.

   Measure:

   • git.exe
   • conhost.exe
   • total process starts
   • input latency

   B — network-free background remote metadata

   Keep local origin discovery enabled.

   Change only:

   • background default-branch/origin inspection cannot contact remote;
   • no remote show network path;
   • no GCM.

   Expected result:

   • git-remote-https.exe = 0
   • git-credential-manager.exe = 0
     during ordinary chat/sidebar activity.

   This may not materially reduce the thousands of local Git starts, and that is useful separation.

   C — registry/tool discovery

   Keep Git behavior unchanged.

   Suppress/cache only the Desktop path responsible for the repeated reg.exe starts.

   Expected result:

   • direct reg.exe children collapse from thousands toward a small bounded number.

   This would tell us whether registry discovery is another independent contributor to UI input pressure.

   D — process cleanup

   Keep A/B/C stock.

   Bound only taskkill / tree cleanup.

   Expected result:

   • no accumulation or overlapping cleanup helpers;
   • no WMI cleanup feedback loop.

   Current-build regression value

   The strongest reason I am posting this is that the failure family is still reproducible on:

   OpenAI.Codex_26.810.4967.0_x64

   That is substantially newer than the builds discussed in the June/July reports.

   The earlier #29949 copied-runtime intervention was strong evidence that suppressing Desktop WMI/Git discovery could materially reduce input delay. This new capture shows that the current Desktop build can still enter an extremely high Git/console/registry process-creation regime.

   So I would not treat the July findings as historical only.

   What this trace does and does not prove

   It proves:

   • severe short-lived process churn exists on this current Desktop build;
   • thousands of Git and console-host processes are created;
   • the Desktop main ChatGPT.exe is a direct parent of thousands of git.exe and reg.exe starts;
   • peak fan-out can reach 179 process creations in one second;
   • background remote/GCM chains still occur with a ChatGPT Sites remote;
   • the machine does not need to be RAM-starved or in a sustained DPC storm for the user-visible system stutter to occur.

   It does not yet prove:

   • the exact JS invalidation call site in this current minified build;
   • that every reg.exe start belongs to the same refresh generation as git-origins;
   • exact per-event mouse latency because no manual lag markers were recorded in this run;
   • that the Sites/GCM branch is responsible for the bulk of the local Git storm.

   Those are exactly the next points I would instrument rather than infer.

   Suggested upstream acceptance tests

   I would add Windows regression budgets at the product level:

   1. Idle valid repository

      • bounded, near-zero background Git process rate after initial discovery.

   2. 100 historical task directories resolving to 3 repositories

      • process count scales with 3 repositories, not 100 task directories.

   3. Repeated sidebar invalidation while one scan is in flight

      • no overlapping equivalent Git-origin fan-out.

   4. Invalid/empty .git

      • one failed detection followed by negative cache/backoff, not a tight retry loop.

   5. ChatGPT Sites remote present

      • ordinary chat/sidebar activity launches no git-remote-https and no GCM.

   6. Active local command traffic

      • no repeated global WMI/registry discovery per command lifecycle event.

   7. Windows input-latency budget

      • low-level mouse/keyboard delivery remains within a defined threshold during active repository work.

   8. Process-creation budget

      • no hundreds/thousands of short-lived Git/console processes per minute.

   If useful, I can provide a sanitized table of process-start timestamps, parent PIDs and the 40-minute system summary. I would not publish the raw bundle unchanged because it contains local workstation/repository metadata.

   I think the highest-yield place to look now is the Desktop-side invalidation/scheduling layer above git-origins, not Git for Windows itself: specifically how sidebar_workspace_task_groups_task_dirs (or its Desktop equivalent) is generated, deduplicated, invalidated, and allowed to overlap with prior generations. The 3,221 direct reg.exe starts are the second coordinate I would inspect in parallel because they suggest another Desktop refresh path may be participating in the same amplification.
5. tmesias commented on Sep 2, 2026

   

   tmesias

   on Sep 2, 2026

   Author

   More actions

   I have a few additional data points from continued testing.

   On my affected Windows workstation, the behavior now appears strongly tied to profile-local Codex/VS Code state rather than the machine, hardware, or workspace alone.

   Control test:

   • Same workstation: AMUSCOLTDW11001
   • Same workspace: P:\smm.011233
   • Genuine Windows reboot before testing
   • Affected Windows profile: reproduced PID 4 handle growth
   • Alternate Windows profile on the same machine: did not reproduce

   Five-minute handle-only samples:

   • Affected profile: about +4.269 PID 4 handles/sec by regression
   • Alternate profile on same machine: about -0.686 PID 4 handles/sec by regression
   • Separate healthy workstation controls were also near background, around +0.046 to +0.340 handles/sec by regression

   I then tested a mitigation on the affected profile:

   1. Close VS Code and Codex.
   2. Temporarily move %USERPROFILE%\.codex\sessions out of the active profile and remove/update session_index.jsonl.
   3. Start VS Code/Codex once with that session history absent.
   4. Close VS Code/Codex again.
   5. Restore the sessions and session_index.jsonl.
   6. Restart and retest.

   After that remove/restart/restore cycle, the affected profile's five-minute samples dropped materially. A recent sample with Codex open measured about +0.480 PID 4 handles/sec by regression, versus earlier material growth around +1.6 to +4.3 handles/sec and much older severe runs above +15 handles/sec.

   This makes me suspect stale derived profile-local state, such as session/sidebar/project indexes generated from historical sessions, rather than the raw session JSONL files alone. The workaround is not proven permanent, but it may be a useful diagnostic/mitigation for others seeing persistent PID 4 handle growth on Windows.

   Important caution: back up %USERPROFILE%\.codex\sessions and session_index.jsonl before trying this. Do not delete local session history unless you are comfortable losing it.
6. VijayAundhekar commented on Sep 7, 2026

   

   VijayAundhekar

   on Sep 7, 2026

   Last edited by VijayAundhekar

   More actions

   Independent IDE-extension reproduction with PoolMon and an empty .git trigger

   I reproduced this issue on a separate Windows workstation and can add a pool-tag coordinate plus a likely local trigger.

   Environment

   • Windows 11 25H2, build 26200.9278
   • VS Code 1.126.0
   • OpenAI Codex VS Code extension openai.chatgpt@26.707.91948 (win32-x64)
   • Git for Windows
   • 32 GB RAM
   • Codex was kept installed and active throughout the measurements

   Process-creation measurement

   A fresh 10.23-second all-process CIM sample captured:

   • 49 unique git.exe processes: approximately 287 total Git processes/minute
   • 32 were direct children of VS Code extension-host PID 13720: approximately 188 direct launch chains/minute
   • the remaining Git captures were child Git processes

   Representative command:

   git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
   

   code --status independently identified PID 13720 as extension-host [1] and showed the Codex codex.exe ... app-server beneath that host.

   Kernel pool measurement

   Across fresh PoolMon points from 13:45:36 through 15:05:41 local time (80.1 minutes):

   • Toke: 559.20 -> 801.99 MiB (+242.79 MiB, ~3.03 MiB/min, ~182 MiB/hour)
   • total paged pool: 1,917.72 -> 2,463.09 MiB (+545.37 MiB, ~409 MiB/hour)
   • companion security tags also rose: SeAt +42.86 MiB, SeTd +16.07 MiB, SeTl +14.28 MiB, SeDt +11.73 MiB

   During the broader 88-minute window, user-mode commit fell by 6.89 GiB (mainly an ~8.08 GiB vmmemWSL private-byte release), while Toke and paged pool continued rising. No WHEA, bugcheck, Kernel-Power 41, resource-exhaustion, Docker OOM/restart, display, or NVIDIA event occurred. This isolates the growth from ordinary user-mode/WSL pressure.

   Exact empty .git finding

   The currently open VS Code workspace root contains an empty .git directory (0 entries). git rev-parse --show-toplevel returns exit 128 there. A valid nested repository under that workspace has a normal non-empty .git directory and resolves correctly.

   This strongly connects the IDE-extension reproduction here with the empty/invalid .git reproducer in #30926. The empty marker has not yet been renamed because the goal was first to preserve the live evidence and keep Codex continuously active. The next proposed intervention is a reversible rename of only that empty invalid .git directory, without restarting VS Code or Codex, followed by the same Git-process and PoolMon measurements.

   Mitigation request

   Official Codex IDE settings currently document no chatgpt.* control for Git-origin discovery, polling interval, or sidebar historical-task-directory scanning. Please add a supported way to disable or bound background Git-origin discovery while leaving Codex chat/agent functionality active. Positive/negative caching, canonical repository-root deduplication, cancellation/single-flight, and a concurrency cap would also address this failure mode.

   No private repository paths, session contents, raw logs, or account data are included here. I can provide sanitized time series if a maintainer requests them.

   Exact-version upstream match found

   After posting the initial evidence, I found #28631, including this confirmation, on the exact same extension build 26.707.91948. That report traced the invalid-.git watcher loop and found that renaming the empty directory stopped repeated rev-parse executions immediately without reloading VS Code or restarting the extension host. This makes the reversible invalid-marker rename the highest-value local A/B intervention here.

   Controlled live intervention result

   The user then renamed only the empty invalid .git marker while keeping VS Code, the extension host, and Codex app-server continuously running.

   • Before: 49 unique git.exe processes in 10.23 seconds; 32 were direct extension-host children.
   • After: 0 git.exe processes in a 15.06-second all-process sample.
   • The extension-host and codex.exe PIDs/creation times remained unchanged, confirming no restart or disable occurred.
   • The first fresh PoolMon interval after the intervention remained nearly flat: Toke 802.93 -> 803.29 MiB (+0.36 MiB/10 min) and total counter paged pool decreased 0.74 MiB. Earlier severe intervals were about +31 MiB Toke per 10 minutes. Because the pool slope had begun slowing before the rename, additional fresh points are being collected before attributing the pool change solely to the intervention.

   The immediate elimination of the Git loop without restarting Codex independently reproduces the workaround reported in #28631 on the same extension build.