1.133.0 cell diagnostics spawn one whole-workspace ripgrep search per code cell (--no-ignore), freezing VS Code on workspaces with an embedded venv

[bartzbeielstein]

Bug description

After the extension auto-updated to 1.133.0, opening or editing a .qmd
with many Python code cells spawns hundreds of concurrent ripgrep
processes through VS Code's search service — we captured a peak of 255
simultaneous rg processes, several above 150 % CPU, which made the machine
unusable and forced repeated VS Code restarts. The behavior started the day
1.133.0 was released and did not occur with 1.132.0.

Each rg process is a whole-workspace file search for one of the virtual
documents the extension creates per code cell:

/Applications/Visual Studio Code.app/.../@vscode/ripgrep-universal/bin/darwin-arm64/rg
    --files --hidden --case-sensitive --no-require-git
    -g **/.vdoc.6aba7a6c-be5a-4f5a-8cd7-46569cc24503.py
    -g !**/.git -g !**/.svn -g !**/.hg -g !**/.DS_Store -g !**/Thumbs.db
    --no-ignore --no-config --no-ignore-global

Three properties make this pathological:

1. One search per cell, re-triggered while editing (the
   quarto.cells.diagnostics.debounceDelay of 500 ms is far shorter than the
   search duration, so processes stack up faster than they finish).
2. --no-ignore --no-ignore-global — the search cannot skip
   .gitignored directories. Our workspace has its uv-managed venv at the
   root (.venv/, ~48,000 files, ignored via .venv/.gitignore), so every
   single search crawls all 48k files and takes ~20 s. The exclusion set in
   the command line (.git, .svn, .hg, .DS_Store, Thumbs.db) is
   exactly VS Code's files.exclude default, i.e. the signature of a
   workspace.findFiles(pattern) call with no custom excludes.
3. The searched filenames (/.vdoc.<uuid>.py) are the per-cell virtual
   documents introduced for the new cell diagnostics feature (Cell diagnostics #980), and the
   storm stops completely when quarto.cells.diagnostics.enabled is set to
   false, so the new feature is the trigger.

The parent of every rg process is VS Code's extension-API search host
(Code Helper (Plugin), node.mojom.NodeService), confirming the searches
come through the extension API rather than user-initiated search.

Workaround

// settings.json
"quarto.cells.diagnostics.enabled": false,
// defense in depth: cap any residual findFiles at the project tree
"files.exclude": { "**/.venv": true }

immediately ends the storm (verified: zero rg processes over a 6-minute
observation window after a window reload, same editing activity).

Steps to reproduce

1. Create a workspace whose root contains a large directory that is not in
   VS Code's files.exclude (a Python venv is the canonical case:
   uv venv && uv pip install jupyterlab lightgbm scikit-learn yields tens
   of thousands of files; the venv being gitignored does not help because
   the searches run with --no-ignore).
2. Install the Quarto extension 1.133.0 and the Python extension.
3. Open a .qmd containing a few dozen Python code cells and type in some of
   them.
4. Watch the process count: watch -n 2 'pgrep -x rg | wc -l'. Within a
   minute or two it climbs into the dozens-to-hundreds, each process pinned
   on enumerating the venv.

Observed on a Quarto book project with 15 chapters of ~30 cells each; the
peak of 255 concurrent rg processes was recorded by a ps sampler within
seconds of opening one chapter.

Actual behavior

While the storm is active:

• the extension host is repeatedly flagged unresponsive
  (Extension host (LocalProcess pid: …) is unresponsive.), with the
  profiler attributing the time to the Python extension stack that the
  diagnostics feature activates (ms-python.python is activated with
  root cause: quarto.quarto);
• even the extension's own activation can fail:
  Not activating extension 'quarto.quarto': Timed out while searching for 'workspaceContains' pattern **/*.{qmd,rmd},... — the workspaceContains
  file search times out against the saturated search service.

Expected behavior

Cell diagnostics should not need a whole-workspace file enumeration per cell
per edit. If a findFiles-style lookup of the vdoc URI is required at all, it
should (a) be cached or scoped to the workspace root rather than globbed
recursively, (b) honour ignore files / default excludes so a venv or
node_modules is never crawled, and (c) be coalesced so that concurrent
searches cannot pile up unboundedly.

Your environment

Component	Version
Quarto extension	1.133.0 (regression; 1.132.0 unaffected)
VS Code	1.122.1 (8761a5560cfd)
OS	macOS 26.5.1 (arm64)
Quarto CLI	1.9.36
Python tooling	ms-python.python, ms-python.vscode-python-envs, astral-sh.ty
Workspace	Quarto book, venv at root with ~48k files (uv)

Possibly related (vdoc lifecycle / large-workspace scans): #939, #855, #819, #799.

[bartzbeielstein]

P.S.: Situation is not fully clear, I also deactivated the SARIF Viewer for Visual Studio Code (Microsoft).