Fix VS Code High CPU Usage and Slow Indexing in Big Workspaces

If you’ve opened a large repo in VS Code and watched your fan spin up like it’s launching a rocket, you already know what VS Code high CPU usage feels like. It usually shows up during indexing, right after you open a monorepo or a project with a bloated node_modules folder. I’ve hit this on three different machines now, and the cause is almost never what the error messages suggest.

Let’s get into what’s actually happening under the hood, because “restart VS Code” is not a real fix — it’s a nap, not a cure.

Quick Answer

If you’re in a hurry, here’s the short version:

• Exclude node_modules, .git, dist, and build folders from search and file watching
• Disable or scope down extensions that run their own language servers (ESLint, TypeScript, Python)
• Turn off Workspace Trust prompts eating CPU on startup scans for huge folders
• Check if a single extension’s language server is looping — Process Explorer will show you
• If none of that works, split the workspace into smaller folders instead of one giant repo

That covers most cases. But if it doesn’t, keep reading, because the deeper causes are worth understanding.

Why VS Code Eats CPU on Large Workspaces

There isn’t one single villain here. From what I’ve seen, it’s usually a combination of these:

1. The file watcher is watching too much. VS Code uses a file system watcher (built on Node’s fs.watch under most platforms) to detect changes for search, git status, and IntelliSense. On a workspace with hundreds of thousands of files — think node_modules, .next, target for Rust/Java builds — that watcher chokes. It’s not built to ignore folders by default; you have to tell it.

2. Language servers indexing everything, including junk. TypeScript’s server (tsserver), Python’s Pylance, and Java’s language server all build an in-memory model of your project. If your tsconfig.json doesn’t exclude node_modules explicitly (even though TS usually skips it), or if you’ve got a jsconfig.json with a loose include pattern, the indexer will try to parse dependency code it doesn’t need to.

3. Extensions running redundant scans. This one’s sneaky. GitLens, for example, does a lot of git blame calculation in the background. So does the built-in Git extension when you’ve got a huge commit history. Combine two or three extensions all polling git or the filesystem independently and you get CPU contention that looks like “VS Code is just slow” when it’s really “five things are fighting for the same core.”

4. Workspace Trust and startup folder scanning. Less talked about, but real — when VS Code opens an untrusted folder for the first time, it does a scan to check for things like .vscode tasks and workspace settings that could run automatically. On a huge repo this scan itself burns CPU before you’ve even opened a file.

Common Scenarios

This shows up differently depending on your setup:

• Monorepos (Nx, Turborepo, Lerna): indexing spikes hard on open because there are multiple package.json files and often multiple tsconfig.json references
• WSL2 on Windows: file watching across the Windows/Linux boundary is noticeably slower, and CPU usage on the WSL side can spike even when the Windows Task Manager looks fine
• Remote-SSH workspaces: the CPU load actually happens on the remote machine, so your local fans stay quiet while the remote server chugs — this trips people up constantly
• macOS with case-insensitive volumes: file watcher behavior differs slightly and can double-scan in some edge cases

Technical Comparison: Common Fixes and What They Actually Do

Reinstalling is the one people jump to first and it almost never helps. I get why — it feels like doing something. But if the config is what’s broken, a fresh install just recreates the same problem in a clean shell.

Step-by-Step Fixes

Step 1: Exclude Heavy Folders From Watching and Search

Open your workspace settings.json (Cmd/Ctrl+Shift+P → “Preferences: Open Workspace Settings (JSON)”) and add:

json

{
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/.git/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/.next/**": true,
    "**/target/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.exclude": {
    "**/.git": true
  }
}

This alone fixes a good chunk of cases. Not all of them, but a good chunk.

Step 2: Check Process Explorer Before Guessing

Go to Help → Open Process Explorer. This shows you every extension host process and its CPU usage in real time. If one extension is sitting at 40%+ CPU doing nothing visible, that’s your suspect. Don’t skip this step and go straight to disabling extensions randomly — you’ll waste an hour.

Step 3: Scope TypeScript/JavaScript Indexing

If you’re on a JS/TS project, add an explicit exclude in tsconfig.json:

json

{
  "exclude": ["node_modules", "dist", "build", "**/*.spec.ts"]
}

And if tsserver still crawls, bump its memory limit in settings:

json

"typescript.tsserver.maxTsServerMemory": 4096

Default is often too low for big codebases and the server just restarts in a loop, chewing CPU each time.

Step 4: Disable Extensions Selectively, Not All at Once

Run code --disable-extensions to confirm the problem is extension-related at all. If CPU drops immediately, re-enable extensions in batches of 3–4 until it spikes again. Tedious, yes. But it’s the only reliable way to isolate the actual culprit instead of guessing.

Step 5: For WSL2 — Move the Project Into the Linux Filesystem

If your project lives under /mnt/c/... and you’re using WSL2, that’s a real bottleneck. Cross-filesystem file watching is slow by design. Moving the project to ~/projects inside the WSL filesystem (not the Windows mount) usually cuts CPU and indexing time dramatically. This one surprises people every time.

What Actually Worked For Me

Honestly, my first attempt was the “disable everything” approach, and it didn’t fully fix it — CPU dropped some, but indexing still took forever on a fairly average-sized Next.js project. I spent probably 40 minutes convinced it was a corrupted extension cache.

Turned out the actual problem was that our .next folder had grown to something like 2GB from months of dev builds nobody cleaned up, and it wasn’t in files.watcherExclude. The file watcher was tracking every single build artifact change in real time. Once I excluded it, CPU usage dropped from a sustained 60-70% down to single digits at idle. Felt a little dumb that it took that long to find, but that’s how it goes sometimes — the fix wasn’t clever, it was just something I’d overlooked.

Advanced Fixes and Edge Cases

Check the actual watcher limit on Linux. If you’re on Linux (native or WSL2) and dealing with a genuinely massive repo, you might be hitting the inotify watch limit. Run:

bash

cat /proc/sys/fs/inotify/max_user_watches

If it’s set low (default is often 8192 or so on some distros), VS Code silently fails to watch everything it should, and behavior gets weird — sometimes manifesting as CPU spikes as it retries. Bump it with:

bash

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Look at Extension Bisect. VS Code has a built-in Help → “Start Extension Bisect” feature that does a binary search across your installed extensions to isolate the offending one automatically. It’s faster than manual disabling and I probably should’ve used it before doing things the slow way.

Check for a runaway git operation. If GitLens or the built-in Git extension is recalculating blame data on a repo with a massive commit history, it can pin a core indefinitely. git gc on the repo occasionally helps, and disabling GitLens’s blame annotations temporarily is a good diagnostic step.

Prevention Tips

• Set up .vscode/settings.json per-project with watcher and search excludes baked in, so new team members don’t hit the same issue on day one
• Periodically clean build folders (dist, .next, target) instead of letting them balloon for months
• Avoid installing overlapping extensions that do the same job (two linters, two git tools) — they compete for the same files
• Keep tsserver memory settings tuned per project size rather than relying on defaults

FAQ

Does reinstalling VS Code fix high CPU usage? Rarely. It resets some cache files but doesn’t touch your workspace settings or extensions, which is where the problem usually lives.

Why does VS Code use more CPU on WSL2 than on native Linux? Cross-boundary file operations between Windows and the WSL2 Linux filesystem are inherently slower — this isn’t a VS Code bug specifically, it’s how the virtualization layer handles file I/O.

Is Pylance slower than the old Python extension? It’s different, not necessarily slower. Pylance does more upfront type analysis, which can look like higher CPU usage on first load, but it’s usually faster once indexing completes.

Can too many open editor tabs cause this? Not directly, no. Tabs by themselves are cheap. It’s usually unrelated to tab count.

Will excluding node_modules break anything? No, and it shouldn’t — excluding it from search and the file watcher doesn’t stop your build tools or terminal commands from working normally.

Editor’s Opinion

Look, most of this comes down to VS Code trying to watch and index way more than it needs to, and nobody telling it not to. The fixes aren’t glamorous. Exclude your junk folders, check Process Explorer before blaming random extensions, and don’t reinstall the whole editor as your first move — that’s rarely it. Your mileage may vary depending on your OS and how messy your repo has gotten over time, but the watcher exclude settings fix this more often than any other single thing I’ve tried.