Bug: Codex IDE sidebar Git-origin polling triggers severe Windows PID 4 Section-handle growth
Summary
On one Windows workstation, enabling the OpenAI Codex VS Code extension causes
a continuous storm of short-lived git.exe and conhost.exe processes. This
correlates with severe accumulation of unnamed Section handles in Windows PID
4 (System), eventually causing system-wide resource exhaustion.
A controlled uninstall/reinstall test reproduced the problem on two Codex
extension builds. Removing Codex stops both the Git process storm and sustained
PID 4 handle growth. Freshly reinstalling Codex makes both return.
Environment
- Operating system: Windows 11 x64
- VS Code: 1.130.0
- Git for Windows installed
- Original affected Codex extension:
openai.chatgpt@26.721.30844
- Freshly reinstalled Codex extension:
openai.chatgpt@26.721.41059
- Repositories include a relatively large set of historical local/network
workspaces associated with prior Codex threads.
Reproduction and controlled results
Codex installed and active
Before uninstall:
- Repeated Git operations appeared every few seconds.
- Representative commands:
git -c core.hooksPath=NUL -c core.fsmonitor= for-each-ref --count=100 ...git config --null --get core.fsmonitorgit -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --abbrev-ref HEADgit -c core.hooksPath=NUL -c core.fsmonitor= remote
- Codex logs identified the repeating request as:
requestKind=git-originssource=sidebar_workspace_task_groups_task_dirs
- PID 4 handle growth repeatedly measured approximately 15–22 handles/second.
- One 20-second sample measured +357 handles (17.85 handles/second).
- A three-minute sample observed 474 new Git processes and 360 new conhost
processes.
Disabling VS Code's built-in Git integration did not stop the behavior.
Removing GitLens and a third-party Claude/Codex history extension also did not
stop it.
Codex uninstalled
After removing openai.chatgpt and confirming that no codex.exe process was
running:
- Three consecutive one-minute PID 4 rates were:
- -0.16 handles/second
- -0.54 handles/second
- +2.68 handles/second
- Zero Git processes were observed.
- An extended 15-minute test averaged 1.02 PID 4 handles/second.
- Zero Git processes were observed throughout that 15-minute window.
Fresh Codex reinstall
After installing openai.chatgpt@26.721.41059:
- PID 4 increased by 1,472 handles in 60 seconds: 24.53 handles/second.
- 172 short-lived Git processes were observed in the same minute.
- The Git commands reproduced the same
core.hooksPath=NUL,
core.fsmonitor=, for-each-ref, rev-parse, and remote pattern.
- The dominant direct parents were active VS Code extension-host processes.
- PID 4 had accumulated more than 624,000 handles when checked.
Kernel/object analysis
Read-only Sysinternals Handle inventories and LiveKD analysis established that
the PID 4 growth is almost entirely unnamed Section handles. Representative
objects had:
- object type: Section
- no name
- access mask:
0x000f001f
- one PID 4 handle
- pointer count: 32767
- one mapped view
- one 4 KB committed pagefile-backed page
The evidence supports the Codex Git-process storm as the repeatable trigger. It
does not establish that Codex itself owns or directly leaks the kernel objects;
the Windows process-creation/teardown path may retain them after the rapid
short-lived process launches.
Expected behavior
The sidebar should not continuously rescan the Git origins of a large
historical task-directory set. Background repository discovery should be
bounded, cached, cancellable when the view is inactive, and should not create
hundreds of processes per minute.
Actual behavior
The Codex sidebar repeatedly scans historical task directories, creating
hundreds of short-lived Git/conhost processes and driving sustained PID 4
Section-handle growth until the workstation approaches resource exhaustion.
Requested investigation
Please investigate:
- The refresh/invalidation loop behind
sidebar_workspace_task_groups_task_dirs.
- Whether Git-origin discovery is duplicated across multiple VS Code
extension hosts/windows.
- Whether repository results can be cached or concurrency/rate limited.
- Whether the internal sidebar Git/PR-origin functionality can be disabled
through a supported setting as a mitigation.
- Why uninstall/reinstall preserves or reconstructs the same historical
task-directory workload.
Sanitized measurements and command lines can be supplied. Full logs, ETL
traces, and live-kernel dumps exist but contain private workstation and
repository information and should not be uploaded publicly.
Bug: Codex IDE sidebar Git-origin polling triggers severe Windows PID 4 Section-handle growth
Summary
On one Windows workstation, enabling the OpenAI Codex VS Code extension causes
a continuous storm of short-lived
git.exeandconhost.exeprocesses. Thiscorrelates with severe accumulation of unnamed Section handles in Windows PID
4 (
System), eventually causing system-wide resource exhaustion.A controlled uninstall/reinstall test reproduced the problem on two Codex
extension builds. Removing Codex stops both the Git process storm and sustained
PID 4 handle growth. Freshly reinstalling Codex makes both return.
Environment
openai.chatgpt@26.721.30844openai.chatgpt@26.721.41059workspaces associated with prior Codex threads.
Reproduction and controlled results
Codex installed and active
Before uninstall:
git -c core.hooksPath=NUL -c core.fsmonitor= for-each-ref --count=100 ...git config --null --get core.fsmonitorgit -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --abbrev-ref HEADgit -c core.hooksPath=NUL -c core.fsmonitor= remoterequestKind=git-originssource=sidebar_workspace_task_groups_task_dirsprocesses.
Disabling VS Code's built-in Git integration did not stop the behavior.
Removing GitLens and a third-party Claude/Codex history extension also did not
stop it.
Codex uninstalled
After removing
openai.chatgptand confirming that nocodex.exeprocess wasrunning:
Fresh Codex reinstall
After installing
openai.chatgpt@26.721.41059:core.hooksPath=NUL,core.fsmonitor=,for-each-ref,rev-parse, andremotepattern.Kernel/object analysis
Read-only Sysinternals Handle inventories and LiveKD analysis established that
the PID 4 growth is almost entirely unnamed Section handles. Representative
objects had:
0x000f001fThe evidence supports the Codex Git-process storm as the repeatable trigger. It
does not establish that Codex itself owns or directly leaks the kernel objects;
the Windows process-creation/teardown path may retain them after the rapid
short-lived process launches.
Expected behavior
The sidebar should not continuously rescan the Git origins of a large
historical task-directory set. Background repository discovery should be
bounded, cached, cancellable when the view is inactive, and should not create
hundreds of processes per minute.
Actual behavior
The Codex sidebar repeatedly scans historical task directories, creating
hundreds of short-lived Git/conhost processes and driving sustained PID 4
Section-handle growth until the workstation approaches resource exhaustion.
Requested investigation
Please investigate:
sidebar_workspace_task_groups_task_dirs.extension hosts/windows.
through a supported setting as a mitigation.
task-directory workload.
Sanitized measurements and command lines can be supplied. Full logs, ETL
traces, and live-kernel dumps exist but contain private workstation and
repository information and should not be uploaded publicly.