workspace.findFiles spawns unbounded parallel ripgrep processes with --no-ignore on bulk file changes

[theRealAbdurrahman]

Bug Description

When extensions call workspace.findFiles() in response to file-change events during a bulk file operation (~174 files created by npx cap sync), VS Code spawns 55+ parallel ripgrep processes — one per findFiles call — with no debouncing, batching, or process pooling. Each process uses 14 threads, saturating the CPU at 95% system / 0% idle for an extended period.

The ripgrep processes also use --no-ignore, causing them to scan gitignored build artifacts (54,306 files / 2.5 GB in an iOS SPM .build/ directory).

Environment

• VS Code: Insiders (latest as of 2026-03-19)
• OS: macOS Darwin 25.3.0 (Apple Silicon, 14 cores)
• Project: React + Capacitor app with iOS SPM dependencies

Reproduction Steps

1. Open a project containing a large gitignored directory (e.g., iOS SPM .build/ with ~54K files)
2. Install an extension that uses FileSystemWatcher + workspace.findFiles() on change events (e.g., nucllear.vscode-extension-auto-import or steoates.autoimport)
3. Create ~100+ files in the workspace at once (e.g., npx cap sync copying JS build output)
4. Observe Activity Monitor — 55+ rg processes spawn simultaneously

Root Cause Trace

We traced the parent process chain using ps -eo pid,ppid,command:

rg (55 instances, PID 79202-79243) → PID 73535 → "Code - Insiders Helper (Plugin)" (extension host)

Every instance runs this identical command:

.../Code - Insiders.app/.../node_modules/@vscode/ripgrep/bin/rg \
  --files --hidden --case-sensitive --no-require-git \
  -g **/*.{js,jsx,ts,tsx} \
  -g !**/.git -g !**/.svn -g !**/.hg -g !**/.DS_Store -g !**/Thumbs.db \
  -g !**/node_modules -g !**/__pycache__ -g !**/.pytest_cache \
  -g !**/.ruff_cache -g !**/.venv -g !**/*.pyc -g !**/node_modules/** \
  --no-ignore --follow --no-config --no-ignore-global

Verification

Condition	rg processes	System CPU	Idle
VS Code closed + bulk file create	0	5%	86%
VS Code open + extensions installed + bulk file create	55	95%	0%
VS Code open + extensions removed + bulk file create	0	5%	86%

Two Issues

1. No throttling of findFiles → ripgrep spawns

When an extension's FileSystemWatcher fires for each of ~174 created files and each event calls workspace.findFiles(), VS Code spawns a separate ripgrep process for each call. There is no:

• Debouncing (coalescing calls within a time window)
• Batching (combining concurrent identical queries)
• Process pooling (reusing ripgrep processes)

55 parallel ripgrep processes × 14 threads = 770 concurrent threads competing for CPU.

2. --no-ignore bypasses .gitignore for extension findFiles calls

The --no-ignore --no-config --no-ignore-global flags cause ripgrep to scan all directories regardless of .gitignore. In our project, this means crawling 54,306 files (2.5 GB) in a gitignored SPM .build/ directory.

Extensions calling findFiles('**/*.{js,jsx,ts,tsx}') almost certainly don't intend to find JS files inside iOS/Android build artifacts. Respecting .gitignore by default would have prevented the CPU spike entirely even without throttling.

Workarounds

• Remove the offending extensions — resolved the issue completely in our case
• files.exclude in .vscode/settings.json for heavy build directories — the only VS Code setting that prevents extensions from scanning directories (both files.watcherExclude and search.exclude were insufficient because --no-ignore bypasses them)

Extensions Involved

Both are popular auto-import extensions that create FileSystemWatcher on **/*.{js,jsx,ts,tsx}:

• nucllear.vscode-extension-auto-import (340K+ installs)
• steoates.autoimport (2.2M+ installs)

Related Issues

• VSCode seems to spawn a lot of ripgrep processes which completely locks up vscode and my computer #164665 — Multiple ripgrep processes from extension
• ripgrep file search uses too many threads #206030 — Ripgrep file search uses too many threads
• High CPU usage with vscode/resources/app/node_modules/@vscode/ripgrep/bin/rg #248666 — High CPU usage with ripgrep

[osortega]

Abdurrahman (@theRealAbdurrahman) this seems to be an issue with the extensions and not VS Code core?
VS Code provides the API but it's up to the extension to use it correctly and in this case probably debounce calls.

Please file an issue to the extension maintainers instead

[vemvcs]

Hi Osvaldo Ortega (@osortega) . The issue is that for extensions, useIgnoreFiles is currently hardcoded to false:

vscode/src/vs/workbench/api/common/extHostWorkspace.ts

Lines 482 to 484 in 99d79c6

	useIgnoreFiles: {
	local: false
	}

This causes the following rg flag to be set:

--no-ignore
When set, ignore files such as .gitignore, .ignore and .rgignore will not be respected

This is a huge flaw. All searches triggered from any extension have the potential to traverse arbitrarily many files - projects can have many, many gitignored files.

That can easily hog CPUs, freezing VSCode.

Please reopen the issue.

[osortega]

vemvcs Please see #305544 (comment)