Why Does VS Code Use So Much CPU in a Large Project Folder?

You open a big project folder in VS Code, and within minutes your laptop fan is roaring and the editor feels sluggish. Task Manager shows Code using a huge slice of CPU even when you are just reading a file. This is a very common complaint with large projects, and it rarely means your computer is too weak. It means VS Code is busy scanning, indexing and watching far more files than you actually work on.

This guide explains what makes VS Code burn CPU in big folders, how to find the exact culprit on your machine, and which settings calm things down without removing features you need.

Quick Answer

VS Code uses a lot of CPU in large projects because extensions and built-in tools constantly scan and watch every file in the folder, especially huge generated folders like node_modules, dist and .git. Exclude those folders from the file watcher, search and TypeScript or language servers, disable or remove heavy extensions, and CPU use usually drops back to normal within minutes.

What Is VS Code Doing With All That CPU?

Several workers run quietly in the background whenever a folder is open:

• The file watcher monitors every file for changes so the Explorer stays up to date. Tens of thousands of files means constant work.
• Search and text indexing prepare for fast searching across the whole workspace.
• Language servers for TypeScript, Python, C++ and others parse files to power IntelliSense, error checking and jump-to-definition.
• Git integration checks file status repeatedly, which is expensive in enormous repositories.
• Extensions such as linters, formatters and AI assistants may scan files on their own schedules.

None of these is a bug on its own. The problem is scale: a folder with 200,000 files asks each of these workers to do far more than a folder with 2,000 files.

Step 1: Find Out Which Process Is Responsible

Before changing settings, spend two minutes identifying the real culprit:

1. Open the Command Palette and run Developer: Open Process Explorer. This window shows every VS Code process and its CPU use.
2. Look for names like extensionHost, tsserver, or a specific extension using far more than the rest.
3. For a quick experiment, launch VS Code with extensions disabled by running code --disable-extensions from a terminal and open the same folder. If CPU stays low, an extension is the problem.
4. Re-enable extensions in halves to find the heavy one. This binary search finds the offender in a few rounds.

Step 2: Stop Watching Generated Folders

The single biggest win is telling the file watcher to ignore folders you never edit by hand. Add this to your user or workspace settings:

"files.watcherExclude": {
  "**/node_modules/**": true,
  "**/dist/**": true,
  "**/build/**": true,
  "**/.git/objects/**": true
}

These folders change constantly during installs and builds, and every change wakes the watcher. Excluding them does not hide the folders from the Explorer; it only stops the background monitoring. A closely related setting is explained in our guide on excluding node_modules from VS Code search to make it faster, which pairs naturally with this fix.

Step 3: Limit Search and Language Servers

Search indexing over a giant folder also costs CPU and memory. Use search.exclude for the same generated folders so quick searches skip them. For TypeScript and JavaScript projects, a jsconfig.json or tsconfig.json with an exclude list stops the language server from parsing build output. Python users can point the language server at the real source folders only. Large monorepos benefit from opening just the subfolder you are working in instead of the repository root; VS Code treats the opened folder as the whole world, so a smaller folder means a smaller workload.

Step 4: Tame Git in Huge Repositories

In very large repositories, Git status checks can keep a CPU core busy almost nonstop. If you do not rely on the in-editor Git decorations, set "git.enabled": false for that workspace, or at least turn off "git.autofetch": true so VS Code stops polling the remote in the background. You can still use Git from the terminal exactly as before. Microsoft’s own tips and tricks for VS Code also suggest checking the Process Explorer and large-folder behaviour when performance drops.

Step 5: Check Your Antivirus and Hardware Acceleration

On Windows, antivirus software sometimes scans every file VS Code touches, which looks like VS Code itself using CPU. Adding your projects folder to the antivirus exclusion list (only if you trust the code there) removes that double work. Separately, if the editor window itself is slow rather than background processes, toggling hardware acceleration with the --disable-gpu launch flag is worth a quick test, because a misbehaving graphics driver can make rendering expensive.

Common Mistakes to Avoid

• Reinstalling VS Code first. A fresh install with the same giant folder and same extensions behaves exactly the same.
• Disabling every extension forever. Find the one heavy extension and keep the rest; most extensions are innocent.
• Confusing memory with CPU. High RAM use by the renderer is a different problem from background CPU spikes, and the fixes differ.
• Opening the drive root as a workspace. Opening C:\ or your whole home folder asks VS Code to watch your entire computer.

Do Not Forget Integrated Terminals and Watch Tasks

A sneaky source of “VS Code” CPU is actually your own development tools running inside its integrated terminals. A bundler in watch mode, a TypeScript compiler running with --watch, or a test runner re-running on every save all consume CPU continuously, and because they are children of VS Code, system tools often blame the editor. Check your open terminals for watch processes you started hours ago and forgot. Stopping an unneeded watcher, or letting it run only while you actively need live rebuilds, can return a surprising amount of CPU. Similarly, background tasks defined in tasks.json that run on folder open are worth reviewing before you blame the editor itself.

Finally, keep VS Code itself updated. The team regularly improves watcher behaviour, search indexing and extension-host performance, and several historical high-CPU complaints were fixed in ordinary monthly releases. If your editor is many months old, updating is a legitimate first step before deeper surgery, and it costs nothing but a restart.

Conclusion

High CPU in a large project is almost never mysterious once you look: background workers are scanning and watching far more files than your work needs. Use the Process Explorer to spot the busiest worker, exclude generated folders from the watcher and search, trim heavy extensions, and open only the part of the project you are editing. Most users see the fans go quiet after the watcher exclusions alone.

Frequently Asked Questions

Why does VS Code use CPU even when I am not typing?

Because the file watcher, Git checks and language servers keep working in the background. Builds, installs and other tools changing files in your folder all trigger fresh scanning even while you are just reading.

Is it normal for VS Code to use 100% CPU briefly?

Yes, short spikes when a project first opens or after a big operation like npm install are normal. The problem is CPU that stays high for many minutes with no obvious activity.

How do I know if an extension is causing the CPU spike?

Open Developer: Open Process Explorer and watch the extensionHost line, then start VS Code with code --disable-extensions and compare. If the spike disappears, re-enable extensions in groups to find the culprit.

Will excluding folders from the watcher break anything?

No. The folders still exist in the Explorer and your builds still work. VS Code simply stops monitoring them for outside changes, so an external tool updating them may need a manual refresh to show in the editor.

Does opening a smaller folder really help?

A lot. Every background feature works on the opened folder only. Opening a single package inside a monorepo instead of the repo root can cut the number of watched files by ninety percent or more.