You downloaded the RPM and now updates are broken
You download the Visual Studio Code RPM from the Microsoft website and run sudo dnf install code-1.95.0-1743345950.x86_64.rpm. The editor launches. You write some code. Two weeks later, you run your usual system update and notice VS Code is stuck on an old version. The package manager refuses to touch it. You are left wondering why one application ignores the rest of your system.
What is actually happening
Fedora uses dnf as the central package manager. It tracks software through repositories. A repository is a structured directory of packages, metadata, and cryptographic signatures. When you install a standalone RPM file, dnf places the files on your system but does not register the source. The package becomes an orphan. It will not receive automatic updates through dnf upgrade. It will also block dependency resolution if a future Fedora update requires a newer version of a shared library.
Microsoft distributes VS Code through a dedicated repository. The repository contains the latest builds, dependency mappings, and GPG signatures. Adding the repository tells dnf where to look for updates. It also ensures the package manager can verify the cryptographic signature before installing or upgrading. Think of the standalone RPM as a one-time purchase. The repository is a subscription that keeps the software aligned with your system.
Fedora's package manager reads repository definitions from /etc/yum.repos.d/. Files in /etc/ are meant for user modifications. Files in /usr/lib/ ship with the base system and should never be edited manually. When you place a .repo file in /etc/yum.repos.d/, dnf parses it on every transaction. The file contains the base URL, the GPG key path, and metadata refresh intervals. If the metadata is stale, dnf will report outdated package lists. Running dnf upgrade --refresh forces a metadata pull. This is the normal weekly maintenance command. Do not confuse it with dnf system-upgrade, which crosses major Fedora releases.
Run dnf repolist first. Read the actual source list before guessing.
The fix
You need to register the official Microsoft repository and import the signing key. Microsoft changed the repository URL structure recently. The old fedora/38 paths are deprecated. The current stable path uses the centos/9 directory because the package metadata is compatible across RHEL-based distributions. This does not mean you are installing CentOS software. It means the repository layout follows the same RPM ecosystem standards.
Here is how to add the repository and install the editor in one transaction.
sudo dnf install https://packages.microsoft.com/centos/9/prod/msft-vscode.repo
# The URL points to a .repo file. DNF will place it in /etc/yum.repos.d/
# This registers the source for future dnf upgrade commands
# DNF automatically parses the baseurl and gpgcheck directives inside
sudo dnf install code
# DNF reads the new repo, resolves dependencies, and installs the package
# The transaction will prompt for confirmation before writing files
# Dependencies like libsecret and gtk3 are pulled from Fedora's main repos
The repository file lands in /etc/yum.repos.d/. You can verify the repository is active by checking the repository list.
dnf repolist
# Lists all enabled repositories and their package counts
# Look for a line containing msft-vscode or code
# The package count confirms metadata downloaded successfully
If the repository shows up with a package count greater than zero, the metadata downloaded successfully. You can now install VS Code using the standard package manager workflow.
sudo dnf install code
# Fetches the latest version from the registered repository
# Verifies the GPG signature against the imported key
# Installs the editor and all required runtime libraries
Snapshot the system before the upgrade. Future-you will thank you.
Verify it worked
Run the version command to confirm the installation. The output should match the latest release on the Microsoft website.
code --version
# Prints the editor version, commit hash, and Electron version
# Confirms the binary is on your PATH and executable
# Mismatched versions indicate a stale cache or wrong repo
Check the repository status to ensure updates will flow correctly.
dnf repoquery --available code
# Shows the latest available version in the repository
# If this matches code --version, you are fully updated
# A higher version here means dnf upgrade will pull it next
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and what the error looks like
The most common failure is a GPG key mismatch. Microsoft rotates signing keys occasionally. If the repository metadata references a key that your system does not trust, dnf will abort the transaction.
Error: GPG check FAILED
Failing package is code-1.95.0-1743345950.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-microsoft
The fix is to import the current key directly from Microsoft.
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
# Fetches the public key and adds it to the RPM database
# DNF will use this key to verify future package signatures
# The key is stored in /var/lib/rpm/gnupg/ for transaction checks
sudo dnf clean all
# Clears cached metadata so DNF re-fetches the repository index
# Forces a fresh metadata pull on the next dnf command
# Prevents stale package lists from blocking the installation
Another frequent issue is the Flatpak version. Fedora ships with Flatpak enabled by default. If you installed VS Code from Flathub, you will have two separate installations. The Flatpak version runs in a sandbox and uses the com.visualstudio.code identifier. The RPM version uses the code identifier. They do not share extensions or settings. Running code in the terminal will launch the RPM version. Running flatpak run com.visualstudio.code launches the sandboxed version.
If you see [FAILED] Failed to start code.service or similar unit errors, check the journal. VS Code does not run as a systemd service. The error usually comes from a leftover desktop entry or a conflicting extension manager.
journalctl -xeu code
# Reads the journal for the code unit with explanatory text
# The x flag adds context, the e flag jumps to the end
# Most sysadmins type this muscle-memory style for quick triage
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The editor runs fine under default policies. Manual context overrides usually break more than they fix.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use the official RPM repository when you want seamless system updates and native integration with Fedora's dependency resolver. Use the standalone RPM download when you are on an air-gapped machine or need a specific historical version for testing. Use the Flatpak version when you want strict sandboxing and do not mind managing extensions separately. Use the Snap package when you are running Ubuntu or Debian and cannot modify the system package manager. Stay on the RPM repository if you only deviate from the defaults occasionally.