How to Check if VSCode Extensions are Safe | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

How to Actually Check if a VS Code Extension is Safe Before You Install It

Ishaan Agrawal

5 min read·<br>Just now

Listen

Share

You’re about to install a VS Code extension. Maybe it’s a formatter, a linter, a theme, an AI tool. You search, you find it, it has decent reviews. You click Install.<br>But here’s what you probably didn’t check — and what almost nobody does.

What VS Code Extensions Can Actually Do<br>Before we get into how to evaluate one, it’s worth being clear about what you’re giving permission for. VS Code extensions run with full access to:<br>Your filesystem — read, write, delete<br>Your environment variables — including secrets, tokens, and credentials your shell exposes<br>Network connections — outbound requests to anywhere<br>Child processes — spawning terminals, shell commands, background workers<br>Other extensions — via the extension API<br>There is no sandbox. When you install an extension, you’re running code with your own user permissions. The same permissions that can push to your git repos, read your .env files, and access your SSH keys.<br>This isn’t hypothetical. Extensions with millions of installs have been caught doing exactly these things.

The Checklist Most Developers Skip<br>Here’s what a 60-second review actually looks like:<br>1. Look at the publisher, not just the extension name<br>Anyone can publish to the VS Code Marketplace. The publisher ID is the only stable identifier — the display name can be anything, and typosquatting is real.<br>Is the publisher verified (blue checkmark)?<br>Does the publisher have other extensions, a website, a GitHub presence?<br>Does the publisher name look like a real organization or a random string?<br>Legitimate extensions from major companies (Microsoft, Prettier, ESLint) will have recognizable, verified publishers. A one-off extension with a publisher ID like devtools-pro-2024 is worth extra scrutiny.<br>2. Check when it was last updated<br>An extension that hasn’t been touched in 2+ years is a supply chain risk waiting to happen. Old dependencies, unmaintained code, and abandoned repos are exactly how attackers get in — either by compromising the account or injecting into a dependency.<br>Look at the “Last Updated” date on the Marketplace listing. Then open the GitHub repo (if it exists) and check the actual commit history. Sometimes the Marketplace listing shows a recent publish date that just reflects an automated re-publish, not real maintenance.<br>3. Look at the package.json permissions before installing<br>Every extension declares what it can do in its package.json. You can find this in the source repo. Look for:<br>activationEvents — when does this extension activate? * means it runs on every file you open.<br>contributes.commands — what commands does it register?<br>Any explicit permission requests<br>An extension that activates on * and makes network calls is doing something the moment you open VS Code, before you've even used it.<br>4. Grep the source for network calls<br>This takes 2 minutes if there’s a public repo. Clone it or browse it on GitHub and look for:<br>fetch(<br>axios<br>http.request<br>https.request<br>xhr<br>WebSocketAre those calls going to localhost, or to an external server? What data is in the request body? A linter that phones home is a red flag. A language server that connects to a known service is expected.<br>5. Check the dependencies<br>The extension’s own code might be clean. Its dependencies might not be. Look at the package.json for third-party packages, then check them against known vulnerability databases. A single compromised npm package can turn a legitimate extension malicious overnight — this is exactly how supply chain attacks work.<br>This is tedious to do manually. Tools like VSCan automate it — paste in an extension ID and get a report on permissions, dependency vulnerabilities, and behavioral flags in seconds.

Red Flags That Should Make You Pause<br>Not all of these are disqualifying, but each one deserves a second look:<br>No public source code. If there’s no GitHub repo (or the repo is empty), you can’t verify what the extension does. This alone should give you pause.<br>Downloads don’t match the repo activity. 500k downloads but 3 GitHub stars and no commit activity? Something is off.<br>Vague description. Malicious extensions often have generic, copy-pasted descriptions that don’t clearly explain what the extension does.<br>Requested permissions don’t match the stated purpose. A Markdown preview extension shouldn’t need to run child processes.<br>Recently transferred ownership. Extensions sometimes get sold. New owners inherit the install base and can push updates. Check the publisher history if you can.

The Specific Extensions Worth Auditing Right Now<br>Some of the most dangerous extensions are the popular ones, because they’re the ones attackers target. If you have any of these installed, it’s worth running a quick check:<br>Extensions you installed years ago and...