Causes VSCode to crash on big projects

[aminya]

Environment (please complete the following information):

• OS (e.g., Windows 10): CachyOS (Archlinux)
• Extension version (e.g., 1.2.3):
  2.1.10

Describe the bug:

I had this issue where the VSCode will crash after some time in a big project. I ran an extension bisect, and Microsoft Edge DevTools was determined to be the culprit. It seems this extension scans files that should be ignored, or it takes too long to analyze some files,s causing the crash. It also seems the scanning is synchronous, which breaks the whole editor.

Repro steps:

Hard to reproduce, but open the extension on big projects

Expected behaviour:

No crashes and no synchronous analysis

Additional context:

[sd592-eng]

Confirming this issue on Edge Tools 2.1.12. In a large Remote-SSH workspace, the renderer heap grows until VS Code crashes. Disabling only Edge Tools and reloading the same workspace removes the persistent file scan and its allocation stack.

Environment

• macOS 26.5.1, Apple Silicon, 32 GB RAM.
• VS Code 1.138.0; Edge Tools 2.1.12; Remote-SSH 0.128.0 connected to Linux.

Observed behavior

1. Open a large directory through Remote-SSH with Edge Tools enabled.
2. Leave the Welcome page or an empty editor open; no Edge preview or debugging session is needed.
3. The renderer heap keeps growing, with a persistent rg --files process on the remote host.
4. Disable Edge Tools and reload the same workspace: the persistent scan disappears and heap usage stabilizes during observation.

Three recorded runs crashed after approximately 44, 50, and 46 minutes. Crashpad reports Reached heap limit, with about 3.90 GiB used against a 4 GiB limit.

Before/after memory comparison

Observation	Edge Tools enabled	Disabled, same workspace reloaded
Renderer heap	Grows toward the 4 GiB limit, then crashes	Around 111–119 MB;
Estimated live allocations in the sampling profile	84.5 MB	0.9 MB
$handleFileMatch search allocation branch	Present	Absent from the sample
Persistent all-file search	Present	Absent in two checks

The largest sampled self-allocations before disabling were:

• deserializeRequestJSONArgs: 39.0 MB.
• mainThreadSearch.addMatch: 31.4 MB.
• URI.revive: 6.7 MB.

About 99.8% of the before-profile allocations were under the remote socket receive callback, including the $handleFileMatch → handleFindMatch → addMatch path.

The sampling intervals differ, so these totals are not an allocation-rate benchmark. Post-disable observation lasted approximately six minutes. No heap-limit increase or other extension disable was applied in this comparison. MB values use decimal units; the 4 GiB limit uses binary units.

Expected behavior

Opening a large workspace should not exhaust the renderer heap. Could you investigate the startup file-type metadata scan in reportFileExtensionTypes() and whether its result collection needs a bound?