A VS Code extension can do anything VS Code itself can do. Microsoft's documentation states that the extension host has the same permissions as the editor, so an installed extension can read your files, use the network and run programs as your user. Treat each install as running third-party code.
What "same permissions" means in practice
Extensions run inside a process called the extension host. The VS Code documentation says that any action VS Code can perform, an extension can also perform through that host. There is no permission prompt per extension, like the ones you see on a phone.
Think of what your own user account can reach on a developer laptop:
| Resource | Reachable by an extension? |
|---|---|
| Source code in open folders | Yes, through the editor APIs |
| Files elsewhere in your home directory | Yes, because it runs as you |
| Terminal and child processes | Yes |
| Network connections | Yes |
| Environment variables and local config files | Yes, same user context |
This is a design fact, not a flaw in any one extension. It is why the choice of what to install matters more than any setting inside the extension.
What protections exist around the install
VS Code and its Marketplace add several layers before and during install. They reduce risk. They do not turn the extension into a sandboxed program.
- Publisher trust prompt. Since VS Code 1.97, the first install from a third-party publisher asks you to confirm that you trust that publisher. Trusting an extension pack also means trusting the publishers of the extensions it depends on.
- Verified publisher badge. The blue check shows the publisher proved domain ownership and has been in good standing on the Marketplace for at least six months.
- Marketplace scanning and signing. The Marketplace runs malware scans on each new extension and each update, and signs extensions so VS Code can check the package on install.
- Removal list. Extensions found to be malicious can be removed from the Marketplace and added to a list so they are removed from users' machines.
Each of these is a filter at the door. None of them limits what a legitimate extension does after it starts, and a trusted publisher can still ship a bad update or have an account taken over.
A short review before you install
- Ask whether you need the extension at all. A built-in feature or a CLI command may do the job.
- Check the publisher, the verified badge and how long the extension has existed.
- Read what the extension says it does with the network and with your code.
- Look at the update history for sudden ownership or behavior changes.
- For teams, restrict installs to an approved list using the allowed extensions setting that the VS Code documentation points to.
For a longer version of steps 2 to 4, see how to vet a VS Code extension before installing.
Limit the blast radius
Separate sensitive work from experimentation. Use a dev container or a separate VS Code profile for projects that hold production credentials, and keep your experimental extensions out of it. Our post on dev containers and extension trust explains what that does and does not change.
Keep long-lived secrets out of files an editor can see. Short-lived credentials limit what a rogue extension can steal.
Safeguard offers VS Code and JetBrains extensions of its own, plus CLI and dependency scanning, so the same checks you run in CI also appear in the editor. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does the verified badge mean an extension is safe?
No. It means the publisher proved control of a domain and has been in good standing on the Marketplace for at least six months. It says nothing about every future update.
Is Workspace Trust a sandbox for extensions?
No. Workspace Trust limits what runs automatically in an untrusted folder. Once you trust a workspace and install an extension, the extension host permissions described above still apply.
Sources
Last reviewed: 19 October 2026.
