Why I Mass-Deleted 41 VS Code Extensions in One Sitting

I have a confession. For about three years I treated my VS Code extensions panel like a junk drawer. Every time I read a blog post about some clever new plugin, I installed it. Every time a coworker mentioned a tool in passing during a stand-up, I installed it. Every time I opened a new language for a side project, I installed three or four extensions for it and never uninstalled them when the project died. By the time I actually looked at the number, I had 41 extensions active across every workspace, and my editor took almost 11 seconds to go from cold start to a blinking cursor I could type in.

Eleven seconds does not sound like much until you multiply it by how many times a day you close and reopen a project, restart after a crash, or switch branches and get prompted to reload the window. I started counting one afternoon out of pure irritation and landed somewhere around 15 reloads a day. That is nearly three minutes of dead time, every single day, just waiting for icons to populate in the sidebar. It is not catastrophic. It is just death by a thousand cuts, and once I noticed it I could not un-notice it.

The audit

I did not delete anything the first day. I opened the Extensions view, sorted by nothing in particular, and just started reading names out loud like I was doing inventory. A shocking number of them I could not explain. I had two separate REST client extensions even though I use Postman for anything serious. I had a spell checker I turned on once for a README and forgot about. I had a Docker extension even though I mostly run Docker commands from the terminal anyway. I had four different icon themes installed, only one of which was active, because apparently past-me liked to comparison shop and never cleaned up.

The worst offenders were the ones running background processes I never asked for. A couple of linters were re-indexing entire node_modules folders on every save because I never scoped their include patterns. One AI-adjacent extension was pinging a remote endpoint on a timer to check licensing status, which showed up clearly once I opened the built-in process explorer with Cmd+Shift+P and typed Developer: Open Process Explorer. That single view is criminally underused. It shows you exactly which extension host processes are eating CPU, and for me it was an eye opener. Three extensions I had genuinely forgotten existed were each sitting between 2 and 6 percent CPU at idle, all day, every day.

What I kept

I ended up keeping eleven extensions total, and I want to be honest that this is not a purity contest. I am not one of those people who thinks a real developer uses vim keybindings and nothing else. I kept GitLens, though I trimmed its feature set way down because the blame annotations on every line were adding real render lag on large files. I kept the Prettier and ESLint integrations because reformatting on save is non-negotiable for me. I kept the official Docker extension after all, because I do actually use the container explorer more than I first admitted to myself. I kept a single icon theme, a single color theme, and the GitHub Copilot extension, though these days I lean on Claude Code from the integrated terminal more than the inline suggestions.

Everything else went. Not disabled, not paused, actually uninstalled. I made a rule for myself going forward: no extension survives more than two weeks without me consciously deciding to keep it. If I install something to solve a one-off problem, it comes back out once the problem is solved, the same way you would not leave a rented tool cluttering your garage after finishing the job.

The actual speed difference

Cold start went from roughly 11 seconds to just under 4. Window reload after a git branch switch dropped from around 6 seconds to under 2. These numbers will look small on a page but they compound. IntelliSense suggestions also got noticeably snappier, especially in a large TypeScript monorepo where before I would type a few characters and wait for the ghost text to catch up. I did not expect that part. I assumed the extension bloat was mostly a startup cost, but it turns out several of the language-adjacent extensions were competing for the same completion provider slot and adding latency to every keystroke's roundtrip.

Memory usage told a similar story. Before the cleanup, the VS Code helper processes on my machine regularly sat around 2.4 GB combined during a normal coding session with a couple of terminals and a browser preview open. After, that number sits closer to 1.1 GB. On a machine with 16 GB of RAM and a browser that is perfectly happy to eat another 3 GB on its own, that difference matters, especially when Docker Desktop is also running in the background chewing through memory for local Postgres and Redis containers.

What I would tell you to check first

If you want to do this audit yourself, do not start by guessing which extensions are slow. Open the process explorer command I mentioned above and just watch it for a few minutes while you work normally. You will see spikes correlate with specific extensions, and that is a much better signal than intuition. Also check your extension list for duplicates in the same category, because that is almost always free savings. Two linters for the same language, two Git extensions, two REST clients, two Markdown previewers. I promise you have at least one of these pairs sitting in your list right now.

The other thing worth checking is workspace-specific versus global extensions. VS Code lets you enable extensions per workspace, and I now use that aggressively. My personal blog repo does not need the same extension set as my main work monorepo, and keeping them scoped means the editor is not loading providers for languages that are not even present in the current folder.

The uncomfortable lesson

What actually stuck with me after doing this is less about VS Code specifically and more about how casually we accumulate tooling debt in general. Extensions are frictionless to install and mildly annoying to remove, so the natural equilibrium trends toward more, not less, unless you deliberately fight it. The same pattern shows up in npm dependencies, in browser tabs, in Slack channels you never mute, in dashboards nobody reads. Cleaning out the extensions panel was a small, mechanical task, but it reminded me to periodically ask what is actually earning its keep versus what just showed up one day and never left.

I now do this audit every quarter, calendar reminder and everything. It takes maybe twenty minutes and it consistently surprises me how much has crept back in. If you have never counted your extensions, go count them right now. I will bet it is higher than you think.

A coworker asked me afterward whether I felt like I had lost anything by cutting so aggressively, and the honest answer is no, not once in the following months did I find myself wishing I still had one of the deleted extensions installed. If anything, the friction of not having a plugin for something has occasionally been useful, it has pushed me to learn the underlying command or shortcut instead of leaning on a plugin's UI wrapper around it, which is a small thing but compounds the same way the extension bloat did, just in the opposite direction. The whole exercise also changed how I evaluate new extensions before installing them now. I ask myself whether I would still want this in three months, whether it duplicates something I already have, and whether it is doing anything in the background I have not explicitly asked for. That last question alone would have caught at least a third of what I eventually ripped out. If you try this audit yourself and find the number lower than you expected, genuinely, that is a good sign, not a sign you did it wrong. The goal was never a specific number of extensions installed, it was making sure everything installed was there because it was earning its place, not because it showed up once during a busy week and nobody ever got around to asking it to leave.