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.

But here's what you probably didn't check — and what almost nobody does.

What VS Code Extensions Can Actually Do

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:

• Your filesystem — read, write, delete
• Your environment variables — including secrets, tokens, and credentials your shell exposes
• Network connections — outbound requests to anywhere
• Child processes — spawning terminals, shell commands, background workers
• Other extensions — via the extension API 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.

This isn't hypothetical. Extensions with millions of installs have been caught doing exactly these things.

The Checklist Most Developers Skip

Here's what a 60-second review actually looks like:

1. Look at the publisher, not just the extension name

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.

• Is the publisher verified (blue checkmark)?
• Does the publisher have other extensions, a website, a GitHub presence?
• Does the publisher name look like a real organization or a random string? 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.

2. Check when it was last updated

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.

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.

3. Look at the package.json permissions before installing

Every extension declares what it can do in its package.json. You can find this in the source repo. Look for:

• activationEvents — when does this extension activate? * means it runs on every file you open.
• contributes.commands — what commands does it register?
• Any explicit permission requests An extension that activates on * and makes network calls is doing something the moment you open VS Code, before you've even used it.

4. Grep the source for network calls

This takes 2 minutes if there's a public repo. Clone it or browse it on GitHub and look for:

fetch(
axios
http.request
https.request
xhr
WebSocket

Are 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.

5. Check the dependencies

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.

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

Not all of these are disqualifying, but each one deserves a second look:

• 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.
• Downloads don't match the repo activity. 500k downloads but 3 GitHub stars and no commit activity? Something is off.
• Vague description. Malicious extensions often have generic, copy-pasted descriptions that don't clearly explain what the extension does.
• Requested permissions don't match the stated purpose. A Markdown preview extension shouldn't need to run child processes.

- 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

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:

• Extensions you installed years ago and forgot about
• Extensions that haven't been updated recently
• Any extension with a name very similar to a well-known one (check the publisher ID carefully)
• AI coding assistants that have broad filesystem and network access by design The "is [specific extension] safe" question is one of the most common things developers search for — and the answer is almost never a simple yes or no. It depends on the version, the publisher's current situation, and the state of its dependencies at any given moment.

A Practical Workflow

Before installing any new extension:

1. Check the publisher is verified or well-known
2. Open the GitHub repo, confirm it's active
3. Scan it through VSCan or check the dependency list manually
4. Look at what events trigger activation Every quarter or so, do a pass over your installed extensions:

# List all installed extensions
code --list-extensions

For anything you don't recognize or haven't used recently: uninstall first, reinstall if you actually need it.

Why This Matters More Than It Used to

A year ago, the threat model for developer tools was mostly theoretical. It's not anymore.

We've seen self-propagating worms targeting VS Code extensions. We've seen extensions with millions of downloads caught harvesting credentials. Microsoft's own telemetry has flagged thousands of extensions with suspicious behaviors.

The attack surface is your entire development environment — your code, your credentials, your git history, your cloud provider tokens. Developers are high-value targets precisely because of what they have access to.

The VS Code Marketplace is not curated the way the iOS App Store is. It's closer to npm: anyone can publish, automated scanning catches some things but not everything, and you're largely responsible for what you run.

That's not a reason to avoid extensions. It's a reason to take 60 seconds before you click Install.

Check your extensions at vscan.dev