VS Code on Fedora: Fixing the Update Button that Opens a Browser

Visual Studio Code installs easily enough on Fedora: grab the .rpm from Microsoft’s website, double-click it (or run rpm -i), and moments later you have a working editor. On Windows and macOS, the equivalent download also brings its own updater along, so new versions arrive automatically. On Fedora, that’s where the trouble starts.

On several of my machines, VS Code installed this way has no idea how to update itself. The “Check for Updates” option in the Help Menu (as well as the big blue Update button that eventually appears) simply open Microsoft’s website so you can download a fresh RPM and do the whole dance again. My ThinkPad P15 is currently sitting on version 1.129.1 doing exactly that. Not ideal.

Why this happens

Unlike its Windows and Mac siblings, VS Code on Linux never updates itself. That’s by design: on Linux, software updates are the package manager’s job, and Microsoft respects that. The app merely checks whether a newer version exists, and if it can’t see a system-managed update path, it falls back to pointing you at the download page.

The missing link is Microsoft’s package repository. When you install the standalone RPM, the repository definition that would let DNF fetch future versions doesn’t reliably get registered on your system, so DNF has no idea where VS Code updates live. The .deb package on Debian and Ubuntu actually asks during installation whether you’d like the apt repository added; the RPM route on Fedora often leaves you with the editor but without the repo. The fix is to register the repository yourself. It takes two commands, and afterwards VS Code updates arrive with your regular dnf upgrade like every other package on the system.

Step 1: Import Microsoft’s signing key

DNF verifies package signatures before installing anything, so first we teach RPM to trust Microsoft’s GPG key:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

Step 2: Add the repository

Next we create a repo definition in /etc/yum.repos.d/. Microsoft’s official documentation suggests a rather hairy echo -e one-liner; I find a heredoc easier to read and to verify:

sudo tee /etc/yum.repos.d/vscode.repo > /dev/null <<'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

A quick word on why it’s sudo tee rather than sudo echo > file: the redirection is performed by your shell before sudo ever runs, so the unprivileged you would be the one trying to write into /etc/yum.repos.d/ — and failing. With tee, the elevated process itself does the writing. The > /dev/null merely suppresses tee’s habit of echoing everything back at you.

You might also notice this avoids dnf config-manager entirely. That’s deliberate: the config-manager syntax changed between DNF 4 and DNF 5 (current Fedora releases ship DNF 5), so half the tutorials out there quote commands that no longer work. A plain repo file is version-proof.

Step 3: Install — or just update

On a fresh system, refresh the metadata and install:

dnf check-update
sudo dnf install code

If VS Code is already installed from the standalone RPM, there’s nothing to uninstall. The package in Microsoft’s repository is the very same code package, so DNF simply adopts it. The next time you run a system update, VS Code comes along for the ride:

sudo dnf upgrade code

Verifying it worked

To confirm the repository is registered and serving packages:

dnf repolist | grep -i code
dnf list --installed code

The first command should show the code repository as enabled; the second shows the installed version. From now on, VS Code updates arrive through DNF with everything else — no more browser detours. Inside the editor, “Check for Updates” will still tell you when a new version exists, but the actual updating is now the package manager’s business, exactly as it should be on Linux.

One small bonus: the same repository also carries code-insiders if you fancy the preview builds. Both editions install side by side without conflict.

Here’s the victory log, courtesy of my 2011 MacBook Pro (which had the same issue, and yes — it runs Fedora too): a successful update replaces the previous rpm (from an “unknown” source) with our new one from the custom repo. That <unknown> in the Repository column is the fingerprint of the whole problem — DNF had no record of where the old package came from, while the new one is properly attributed to the code repo we just registered.

      Arch       Version                              Repository              Size
Upgrading:
 code                                x86_64     0:1.133.0-1786488022.el8             code                 1.0 GiB
   replacing code                    x86_64     0:1.130.0-1784734628.el8             <unknown>            1.1 GiB

Transaction Summary:
 Upgrading:          1 package
 Replacing:          1 package

Total size of inbound packages is 330 MiB. Need to download 330 MiB.
After this operation, 66 MiB will be freed (install 1 GiB, remove 1 GiB).
Is this ok [y/N]: y
[1/1] code-0:1.133.0-1786488022.el8.x86_64                               100% |  18.5 MiB/s | 330.4 MiB |  00m18s
-----------------------------------------------------------------------------------------------------------------
[1/1] Total                                                              100% |  18.4 MiB/s | 330.4 MiB |  00m18s
Running transaction
[1/4] Verify package files                                               100% |   0.0   B/s |   1.0   B |  00m06s
[2/4] Prepare transaction                                                100% |   3.0   B/s |   2.0   B |  00m01s
[3/4] Upgrading code-0:1.133.0-1786488022.el8.x86_64                     100% |  76.1 MiB/s |   1.0 GiB |  00m13s
[4/4] Removing code-0:1.130.0-1784734628.el8.x86_64                      100% | 534.0   B/s |   2.3 KiB |  00m04s
Complete!