A VS Code extension can do nearly anything you can do as your own user. The documentation says extensions run in the extension host, which has the same permissions as VS Code itself, so an extension can read and write files, make network requests, run external processes and change workspace settings.
No permission prompts
Mobile apps ask before touching your contacts. VS Code extensions do not ask before touching your home directory. There is no per-extension permission list to approve. The decision happens once, when you install.
That makes installation a trust decision about the publisher, the code and every update that follows.
What this means in practice
Think through what sits on a developer laptop:
- Source code for private repositories.
- Environment files and configuration with credentials.
- SSH keys and cloud CLI profiles in your home directory.
- Browser sessions and tokens, depending on the machine.
An extension runs with access to the same file system as you. A well-behaved extension reads only what it needs. A malicious or compromised one could read much more. VS Code's documentation lists the file, network and process capabilities as the baseline, not exceptions.
What the platform does to reduce risk
VS Code and its Marketplace add several layers:
- Malware scanning with multiple antivirus engines on each new extension and update, before it becomes public.
- Dynamic analysis of runtime behaviour in a sandboxed virtual machine.
- Monitoring of unusual download and usage patterns.
- A block list that removes reported malicious extensions and automatically uninstalls installed copies.
- Marketplace signing of extensions, verified at install time.
- Secret scanning at publish time.
These help. They are not a guarantee, and the same page tells you to check ratings, reviews, the issue tracker and the license before installing.
What you control
- Install fewer extensions. Each one is code with your permissions.
- Use Workspace Trust so folders cannot trigger code unprompted. It does not stop an extension you installed, as the Workspace Trust page states.
- Use separate profiles so risky or experimental extensions do not follow you into sensitive projects.
- In a team, set an allowlist. See the guide to extensions.allowed.
A useful mental model
Think of an extension like a command line tool you installed with a package manager, one that happens to stay running all day and starts with the editor. You would not run an unknown script as your own user without reading it. The marketplace UI makes installation feel lighter than it is, which is the reason to slow down for a moment.
Common questions about risk
Extensions that format code, lint, or add language support usually have an obvious reason to read project files. The question to ask is whether the extension needs the network, whether it sends anything out, and whether its publisher explains why. An extension with a narrow job and a large list of activation triggers is worth a second look.
Updates deserve the same thought as the first install. A trusted extension can be sold, transferred or compromised later. Settings that delay updates give you a little more time, as described in the auto update guide.
Quick check
Does VS Code sandbox extensions?
The documentation says the extension host has the same permissions as VS Code. Treat an extension as code running as you.
If an extension is in the Marketplace, is it safe?
It has passed scanning, but the documentation still advises reviewing the publisher, reviews and source before installing.
Sources
Last reviewed: 19 October 2026.
