How to Install Visual Studio Code on Linux (Ubuntu, Fedora, Arch)

Visual Studio Code is not in the package archive of Ubuntu, Debian, Fedora, openSUSE, or Arch. Microsoft builds and signs the editor, then publishes it from its own servers.

The Microsoft repository and the Snap Store both update the editor for you. A .deb or .rpm file you install by hand stays at the version you downloaded until you repeat the install.

Where VS Code actually comes from on Linux

Ubuntu and Debian point apt at archive.ubuntu.com and deb.debian.org. Fedora, RHEL, and openSUSE point dnf and zypper at their own mirrors, and none of those archives carries a package named code.

The install command people reach for first has nothing to resolve, and it says so without naming a cause.

The package manager asked every source it knows about and none of them publishes the editor.

Your package manager will not install anything from an archive whose signing key it does not hold, and that one requirement is the whole difference between Microsoft’s repository and any other. Registering the source is the entire task.

A signed archive also settles how the editor updates. Once the source is registered, apt and dnf treat VS Code like any other package on the machine, so it moves forward with your system updates instead of waiting for you to notice a new release.

The editor is an Electron application, which is why the package pulls in a desktop stack even on a machine you reach over SSH.

The install itself is one command per machine. Which command that is depends on the family the machine belongs to.

Which package to use on your distribution

Your distribution’s package manager decides which methods are available, and the way each method updates decides how much attention the editor needs afterwards.

Every command below installs system-wide, so run each one as root or through sudo.

I read both archive indexes on the same day, and Microsoft’s apt source declares amd64, arm64, and armhf while its RPM metadata carries x86_64, aarch64, and armv7hl. Choosing the wrong file on the download page is the usual cause of an architecture error later.

Install from Microsoft’s repository

This route puts VS Code on the same update cycle as the rest of the machine, which is why it is worth the extra two commands when your distribution is on the list above.

On Ubuntu, Debian, and Linux Mint

The signing key goes into a keyring file and the repository goes into a sources file. Both are one-time steps.

sudo apt install wget gpg
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft.gpg

The output path in that second command is deliberate. A key dropped in /etc/apt/trusted.gpg.d is trusted for every source on the machine, while the Signed-By field in the next file scopes this key to Microsoft’s repository alone. If you later take the source back out, the key leaves with it.

sudo tee /etc/apt/sources.list.d/vscode.sources <<'EOF'
Types: deb
URIs: https://packages.microsoft.com/repos/code
Suites: stable
Components: main
Architectures: amd64,arm64,armhf
Signed-By: /usr/share/keyrings/microsoft.gpg
EOF

Then refresh the package list so apt reads the new file, and install the package itself.

sudo apt update
sudo apt install -y code

On a machine with no desktop environment the install also pulls in the GTK stack, so a bare server downloads a few hundred packages for a graphical editor. I watched that on a clean Ubuntu 24.04 install, and dpkg reported code 1.137.0-1788902055 once the queue drained.

On Fedora, RHEL, CentOS, and openSUSE

The RPM route imports the same key into the RPM database, then writes a repository file that tells dnf how to read the archive.

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo tee /etc/yum.repos.d/vscode.repo <<'EOF'
[code]
name=Visual Studio Code
baseurl=https://packages.microsoft.com/yumrepos/vscode
enabled=1
autorefresh=1
type=rpm-md
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc
EOF

The autorefresh and type lines are the part people leave out when they copy an older tutorial. Without them dnf keeps working from a cached package list, which is how a machine ends up months behind on a repository that is reachable and correct.

I kept both lines in the file above, and dnf found the package on its first run without a cache rebuild.

sudo dnf install -y code

I ran the same sequence on Fedora 42, where dnf resolved code 1.137.0 out of the code repository together with the desktop stack the editor needs.

openSUSE and SLE read the same archive from a different directory, and install with zypper. The key import from above still applies.

sudo tee /etc/zypp/repos.d/vscode.repo <<'EOF'
[code]
name=Visual Studio Code
baseurl=https://packages.microsoft.com/yumrepos/vscode
enabled=1
autorefresh=1
type=rpm-md
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc
EOF
sudo zypper install code

The dnf command reference covers the rest of the flags if you want to inspect the repository before installing from it.

Confirm the version you got

I checked the version against Microsoft’s package index and its download API on the same day, and both answered 1.137.0. Ask the shell which binary answers when you type the command.

which code

The path tells you which build is installed. A repository or deb install answers /usr/bin/code, a Snap answers /snap/bin/code, and the Flatpak has to be started through flatpak run. Typing code –version afterwards prints the release you are on.

Install VS Code with Snap or Flatpak

Both of these bypass your distribution’s package manager and carry their own runtime, so the publisher is the part worth checking.

sudo snap install --classic code

The classic flag changes what the Snap can reach. VS Code has to read and write files outside a confined sandbox, and the store grants that only through classic confinement, so the command fails without it and says why. Snap packages on Linux explains what confinement costs you elsewhere.

I checked both listings. The Snap comes from Microsoft and refreshes itself in the background, while the Flatpak on Flathub is built by community maintainers, listed there as unverified by Microsoft, and documented with extra steps for the integrated terminal and for extension features that expect the deb or RPM layout.

flatpak install flathub com.visualstudio.code

Setting Flatpak up on a new distribution covers the setup if the machine does not have it yet.

Install VS Code on Arch Linux

Arch puts Code – OSS in its official repository and the Microsoft build in the AUR, and the two are not interchangeable once extensions enter the picture.

The Microsoft build needs an AUR helper, so add one first if the machine has none. On Arch and Manjaro, enabling the Arch User Repository is the step that makes the command below work.

yay -S visual-studio-code-bin

For the open-source build instead, install the package Arch maintains itself.

sudo pacman -S code

Code – OSS ships the Open VSX registry in place of the Microsoft Marketplace, because Microsoft’s marketplace terms only allow the branded build to use it. Some Microsoft-published extensions refuse to run outside the branded build, and that is the difference that decides which of the two packages you want. The Arch-specific VS Code walkthrough covers the flags and configuration paths for both.

The errors that stop a VS Code install

Almost everything that goes wrong between the signing key and a working editor shows up as one of these messages.

Unable to locate package code

Without the sources file, apt answers with that line. It searches every source it knows and finds nothing, so the file is missing or the package list is stale.

ls /etc/apt/sources.list.d/vscode.sources
sudo apt update

A key that fails to import produces a different error on the next update, and the signature verification failure has its own fix.

package architecture does not match system

That message comes from installing a downloaded .deb or .rpm built for the wrong processor. The repository route avoids it, because the apt source declares the three architectures it serves and apt picks the matching build on its own.

If you install from a file you downloaded, pick the build that matches the machine rather than the one that appeared first on the page.

dependency problems prevent configuration of code

Installing a downloaded .deb with dpkg brings no dependencies with it, so a missing library stops the configuration step halfway. apt resolves dependencies and dpkg does not, which is the whole difference between the two commands.

sudo apt install ./code_1.137.0-*_amd64.deb
sudo apt --fix-broken install

The comparison of apt against dpkg covers when each of them is the right tool.

Conflicts with a code package from another repository

Pop!_OS and a few other distributions ship their own code package, and apt can prefer it. A pin file settles the argument in Microsoft’s favour.

sudo tee /etc/apt/preferences.d/code <<'EOF'
Package: code
Pin: origin "packages.microsoft.com"
Pin-Priority: 9999
EOF

If you later want the source gone, removing an apt repository takes the entry and its key back out in one pass.

Your settings and extensions outlive the install

The package is the disposable part. Settings and extensions live in your home directory, so removing the editor to change method and installing it again brings the same workspace back.

Print the extension list before you switch, and a reinstall becomes a restore.

code --list-extensions

Frequently asked questions