Installing an extension from a VSIX file is legitimate for air gapped machines and pre release testing, but it bypasses the Marketplace listing, reviews and update flow. Auto update is disabled by default for VSIX installs, so you take on verification and patching yourself.
How a VSIX install works
The VS Code documentation describes two routes. In the Extensions view, choose Install from VSIX, or run Extensions: Install from VSIX from the Command Palette. From the command line, run code --install-extension followed by the file name. You can pass the flag several times.
What you give up
The Marketplace provides scanning for new extensions and updates, a block list that removes reported malicious extensions and uninstalls installed copies automatically, and signing that VS Code verifies at install time. Those protections are described for the Marketplace route. A file you download elsewhere does not carry them in the same way, so treat the source as the only evidence you have.
You also lose update flow. Per the documentation, auto update is disabled by default for extensions installed from a VSIX, so a fix released later will not arrive on its own.
When a VSIX is reasonable
- A machine with no internet access.
- Testing a build from your own team before publishing.
- An internal extension that is not on the public Marketplace.
- Pinning a version you reviewed.
A safer way to do it
- Get it from the publisher. Use the project's own release page, not a mirror or a forum post.
- Compare the checksum if the publisher gives one. Compute a SHA-256 of the file and compare. Without a published value you cannot confirm the file is the real one.
- Open the archive. A VSIX is a zip file. Look at
extension/package.jsonfor the publisher, activation events and scripts, and skim the bundled code. - Install in a throwaway profile first. Use a separate profile or a disposable machine.
- Record it. Put the ID, version and source in your extension inventory.
- Set a reminder to check for new versions, since it will not update itself.
Team rules
If you manage machines, an allowlist can still apply. The extensions.allowed setting works on extension IDs and versions, so you can list the exact version you reviewed. See the allowlist guide.
What about enterprise needs
Some organisations distribute approved extensions internally as VSIX files. That can work when someone owns the process: build or fetch the file, verify it, scan it, publish it to a file share, and update it on a schedule. Without that owner, VSIX distribution turns into a collection of stale copies with no update path. If you go this way, treat the internal catalogue like a package registry and give it the same care.
Red flags
Be cautious if the file arrives by email or chat, if the sender asks you to disable a warning, if the publisher in package.json does not match the sender, or if the archive contains minified or encoded code with no source. In any of those cases, do not install on a machine that holds credentials.
Quick check
Is a VSIX from a GitHub release safer than one from a forum?
Usually the project's own release page is a better source, but it is still only as trustworthy as that repository. Check the publisher and read the contents.
Will VS Code update a VSIX extension?
Not automatically by default, according to the documentation.
Sources
Last reviewed: 19 October 2026.
