[Windows][VS Code] Codex extension can trigger thousands of repeated `rg --files` scans after worktree creation

Summary

On Windows 11, with the Codex VS Code extension active, a Codex session triggered a runaway storm of VS Code-bundled rg.exe --files processes in a TypeScript workspace. The storm made the whole machine nearly unusable: terminal paste/input degraded to roughly one character per second, and a separate 5-second system sampler stalled for up to 420.9 seconds.

The direct parent of every recorded rg.exe instance was a single VS Code extension-host/NodeService process (Code.exe --type=utility --utility-sub-type=node.mojom.NodeService). The scans all used the same workspace as cwd.

A single taskkill /F /IM rg.exe terminated 2,581 live rg.exe processes. Instrumentation recorded 4,184 instances with the same dominant command pattern during the incident.

Uninstalling the Codex VS Code extension stopped the rg.exe storm. Running Codex TUI from a standalone terminal outside VS Code does not reproduce the problem on the same repository, so the CLI/TUI itself does not appear sufficient to trigger it.

This may be related to #22421 (Codex VS Code extension spawning many concurrent rg --files processes), but this reproduction is on Windows and the searches target workspace TypeScript files rather than plugin asset paths. It also resembles the Windows extension process-storm/resource-exhaustion pattern in #35775, although that issue involves repeated Git-origin polling rather than ripgrep.

Environment

• OS: Windows 11 x64, build 10.0.26200.8875
• IDE: Visual Studio Code on Windows
• Extension: OpenAI Codex / openai.chatgpt (exact extension version was not captured before uninstalling it)
• Workspace: local TypeScript/Python repository; exact path redacted below
• Codex TUI was started from the VS Code environment during the affected session

Observed process storm

All recorded rg.exe processes had the same direct parent:

parent: Code.exe PID 54548
command: Code.exe --type=utility --utility-sub-type=node.mojom.NodeService ...
rg instances recorded from this parent: 3600+ (4184 with the dominant exact command by the end of capture)

Dominant ripgrep command, sanitized:

<VS Code>\resources\app\node_modules.asar.unpacked\@vscode\ripgrep-universal\bin\win32-x64\rg.exe
  --files
  --hidden
  --case-sensitive
  --no-require-git
  -g **/*.{ts,tsx}
  -g !**/.git
  -g !**/.svn
  -g !**/.hg
  -g !**/.DS_Store
  -g !**/Thumbs.db
  -g !**/node_modules/**
  --no-ignore
  --follow
  --no-config
  --no-ignore-global

All of these ran with cwd similar to:

D:\coding\<workspace>\

The spawn rate was repeatedly around 30-45 new rg.exe processes per 10 seconds. Example 10-second buckets:

22:21:10  35
22:21:20  42
22:21:30  35
22:21:40  46
22:21:50  31
...
22:25:10  34
22:25:20  34
22:25:30  36
22:25:40  38
22:25:50  38
22:26:00  39
22:26:10  45

Restarting the VS Code Extension Host did not stop the behavior; killing the existing rg.exe processes caused new ones to appear again.

Timeline correlation

Process start times were recorded independently of the delayed sampling loop.

Immediately before the first ripgrep burst, the Codex session created a Git worktree:

22:21:09  pwsh.exe ... git worktree add .worktrees/<redacted> ...
22:21:14  first rg.exe burst begins

The worktree operation was launched under the active Codex session in the same workspace.

The storm then continued/recurred for more than 30 minutes.

System impact

A separate memory/process recorder normally samples every 5 seconds. During the rg.exe storm its largest observed sample gaps were:

420.9 s
327.9 s
171.8 s
125.1 s
89.0 s
79.1 s
68.8 s

The machine became so unresponsive that terminal paste/input appeared at roughly one character per second.

At one point:

taskkill /F /IM rg.exe

successfully terminated 2,581 rg.exe processes in one invocation.

Isolation / workaround

Observed controls:

1. Restarting the VS Code Extension Host did not stop the respawning.
2. Killing all current rg.exe processes did not stop the respawning while the affected VS Code/Codex setup remained active.
3. Uninstalling the Codex VS Code extension stopped the rg.exe storm.
4. Running Codex TUI directly from a standalone terminal, outside VS Code, does not reproduce the storm on the same repository/workflow.

Current workaround: run Codex TUI in an external terminal and do not use the Codex VS Code extension in the affected workspace.

Expected behavior

Workspace file enumeration should be bounded, deduplicated, and cancellable. A worktree creation or Codex session update should not cause thousands of overlapping/repeated rg --files invocations from one extension host.

Requested investigation

Please investigate whether the Codex VS Code extension can repeatedly trigger VS Code workspace file enumeration after a worktree is created or the workspace/session state changes.

In particular:

• coalesce/debounce repeated file-enumeration requests;
• cap concurrent rg --files searches;
• cancel superseded searches;
• avoid rescanning the same workspace/glob set in a tight loop;
• add diagnostics identifying which extension request initiated a VS Code rg --files search.

I can provide additional sanitized process-lifecycle and memory/commit data from the recorder if useful.

Related issues

• #22421 — VS Code Codex extension spawns dozens of concurrent ripgrep processes for plugin asset lookups
• #35775 — Codex IDE sidebar Git-origin polling triggers severe Windows process/resource exhaustion