VS Code ripgrep Using 1,100% CPU: Causes and How to Prevent It

Introduction

When VS Code starts spinning up the fans and the rest of the machine slows to a crawl, the cause is often not your code or your extensions. On my machine it was three instances of ripgrep, the file search tool VS Code bundles, each taking several hundred percent CPU and running for more than half an hour. This note explains how that happened, which settings caused it, and the changes that prevent it from happening again. You will get the exact settings.json configuration, a table of what each setting does, and a short list of optional safeguards.

Incident summary

On April 14, 2026, around 14:55, a runaway ripgrep search in VS Code drove the system load to 148 and left the CPU almost fully occupied. The search was caused by the --follow option, which made ripgrep loop through symbolic links while searching files in a Python project. The fix is to stop VS Code from following symbolic links during search and to exclude virtual environment folders from search and file watching.

Key data

Incident overview (April 14, 2026, 14:55)

Item	Value
Load Average	148.01 (normal: 3–5)
CPU idle	0.0%
Offending process	rg (ripgrep) x 3
CPU per process	405%, 400%, 301% (total ~1,100%)
Run time	27–31 minutes each (infinite loop)
Target project	woka-kolmar-edu
Files being searched	curriculum-links.md, case-references.md, prep-checklist.md

ripgrep process details

PID 33843 — rg --files --follow --no-ignore ... -g prep-checklist.md       (27 min, 347% CPU)
PID 14235 — rg --files --follow --no-ignore ... -g curriculum-links.md     (31 min, 389% CPU)
PID 14618 — rg --files --follow --no-ignore ... -g case-references.md      (31 min, 337% CPU)

The key flag combination:

• --follow: follow symbolic links
• --no-ignore: ignore .gitignore rules
• --no-require-git: search even when the folder is not a git repository

Root cause analysis

1. How VS Code searches files: VS Code uses @vscode/ripgrep for file browsing and search. When a workspace opens, it runs rg --files to build the file list.

2. --follow plus the .venv symbolic link: In woka-kolmar-edu/.venv/bin/python, the interpreter is a symbolic link to /opt/miniconda3/bin/python3. Because of --follow, ripgrep followed that link and began traversing all of /opt/miniconda3/.

3. The --no-ignore flag: Even when .gitignore lists .venv/, this flag makes ripgrep ignore that rule. VS Code uses this flag when it performs an “include all files” search.

4. Result: ripgrep crawled tens of thousands of miniconda files and followed additional chains of symbolic links across the system, creating an infinite loop.

Impact

Item	Normal	During incident
Load Average	3–5	148
CPU idle	90%+	0%
Physical memory	~40G	45G (nearly full)
User experience	Normal	Fans at full speed, app response delayed

Insights

Why this problem is common

• It is a known issue with the VS Code plus Python project combination and occurs frequently.
• A .venv/ folder necessarily contains symbolic links, because the Python interpreter inside it is a link.
• VS Code’s default is search.followSymlinks: true.
• If node_modules, .venv, and similar folders are not in search.exclude, they become part of the search.

Preventive measures applied

1. VS Code global settings (applied immediately)

Add the following to ~/Library/Application Support/Code/User/settings.json:

{
    "search.followSymlinks": false,
    "files.watcherExclude": {
        "**/.venv/**": true,
        "**/node_modules/**": true,
        "**/.git/**": true,
        "**/venv/**": true,
        "**/__pycache__/**": true
    },
    "search.exclude": {
        "**/.venv/**": true,
        "**/node_modules/**": true,
        "**/__pycache__/**": true,
        "**/venv/**": true,
        "**/.git/**": true
    }
}

Setting	Effect
search.followSymlinks: false	Blocks symbolic link cycles (removes the root cause)
files.watcherExclude	The file watcher ignores .venv and node_modules, saving memory and CPU
search.exclude	Excludes virtual environment and dependency folders from search scope

2. Optional future safeguards

Safeguard	Method	Effect
Per-project .vscode/settings.json	Specify exclude patterns for each project	Project-specific exclusion patterns
launchd CPU watchdog	Automatically kill any rg process that runs for more than 5 minutes at 200%+ CPU	System protection (over-defensive)
.gitignore maintenance	Always include .venv/, __pycache__/, and similar entries	Effective when VS Code does not use --no-ignore

Key lessons

1. --follow is a risky default: If ripgrep follows symbolic links, it can search the entire file system.
2. Python .venv folders always contain symbolic links: A virtual environment’s interpreter is a symbolic link to the system Python.
3. One global VS Code setting covers every project: You do not need to configure each project separately.
4. Diagnose CPU runaways immediately with ps -Arco pid,pcpu,comm: This is the fastest way to check CPU usage on macOS.

Sources

• VS Code ripgrep issues: https://github.com/microsoft/vscode/issues/search?q=ripgrep+symlink+cpu
• ripgrep --follow documentation: https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md
• VS Code search settings: https://code.visualstudio.com/docs/editor/codebasics#_search-settings

Bottom line

The runaway was caused by ripgrep following a symbolic link from a Python .venv into a full miniconda installation, which the --follow option allowed. Setting search.followSymlinks to false removes the cause, and excluding .venv and related folders from search and file watching limits the damage if something similar happens again. These global settings apply to every project, so you only need to make the change once.