Opening GitHub Pull Requests in VSCodium: What Actually Works and What Doesn't

The problem: GitHub's editor shortcut doesn't know about VSCodium

If you use VSCodium — the community build of VS Code without Microsoft's telemetry and proprietary branding — you've probably noticed a small friction point when reviewing pull requests on GitHub. GitHub's web UI offers an "Open in VS Code" style shortcut that hands a repository off to a locally installed editor via a custom URI scheme. That shortcut targets Microsoft's official VS Code build. There is no native, GitHub-rendered "Open in VSCodium" link.

An earlier draft of this piece claimed otherwise, and that claim doesn't survive scrutiny. So this is the corrected, honest version: what the URI-handler mechanism actually is, what VSCodium registers, and the practical options you have today to get from a GitHub PR page to a local checkout in VSCodium with minimal friction.

How editor hand-off from a browser actually works

The mechanism is a custom URI scheme (sometimes called a protocol handler). An application registers itself with the operating system as the handler for a scheme like vscode://. When the browser encounters a link such as vscode://file/path/to/project, it asks the OS to launch the registered handler and pass the URI along as an argument. The editor then parses the URI and opens the referenced file or folder.

Three separate things have to line up for the one-click experience:

• The website must emit a link using a scheme your editor understands.
• The editor (or its installer) must have registered that scheme with the OS.
• The editor must know how to interpret the URI's payload (a file path, a remote URL, an extension request, and so on).

GitHub controls the first step, and it emits links aimed at VS Code's scheme. VSCodium is a build of the same open-source codebase, so its URI-handling code paths are essentially identical — but the scheme name it registers is a build-time configuration value, and GitHub does not generate links for it.

What VSCodium actually registers

VSCodium's build configuration defines its own protocol scheme (vscodium://) rather than Microsoft's vscode://. Whether that scheme is registered with your OS depends on how you installed it:

• Windows: the official installer registers the scheme; portable or extracted-zip installs generally do not.
• macOS: the scheme is declared in the app's Info.plist, so it registers when the app is first launched — but if both VS Code and VSCodium are installed, each claims its own scheme, which is fine, while any link using vscode:// will still route to VS Code.
• Linux: registration happens via the .desktop file's MimeType=x-scheme-handler/... entry. Package-manager installs usually include this; tarball or AppImage installs may not, and some desktop environments require update-desktop-database before the handler takes effect.

You can check whether the handler is live by pasting a URI into your browser's address bar or running it from a terminal. On Linux: xdg-open "vscodium://file/home/you/someproject" (adjust the path to a real folder). On macOS: open "vscodium://file/Users/you/someproject". If VSCodium opens that folder, the scheme is registered. If nothing happens, the handler is missing — not the editor.

One important caveat: exact scheme behavior has varied across VSCodium releases and packaging methods, so treat the above as a starting hypothesis and verify on your own machine rather than assuming.

A worked workaround: bridging GitHub's link to VSCodium

Since GitHub won't emit vscodium:// links for you, the pragmatic options are:

1. Just use the built-in flow. If you also have VS Code installed, GitHub's shortcut works as designed. Not helpful if VSCodium is your only editor.
2. Rewrite the scheme with a browser extension or userscript. A small userscript (Tampermonkey/Greasemonkey) can rewrite vscode:// hrefs on github.com to vscodium:// before you click. This is the closest thing to a native experience, but it depends on GitHub's DOM and link format, which can change without notice.
3. Register VSCodium as the vscode:// handler yourself. Because VSCodium shares VS Code's URI-parsing code, it can usually interpret vscode:// URIs if the OS routes them to it. On Linux this means adding x-scheme-handler/vscode to the MimeType line of VSCodium's .desktop file and running update-desktop-database. This is unofficial and could conflict with a real VS Code install — only one app can own a scheme.
4. Skip the browser hand-off entirely. The GitHub CLI covers the core workflow reliably: gh pr checkout 123 inside a local clone fetches and checks out the PR branch, then codium . opens it. Two commands, no URI schemes involved, and it works the same on every OS.

For most people, option 4 is the dependable choice and option 2 is the nicest when it works. Options 2 and 3 both rely on unofficial behavior, so build your workflow on option 4 and treat the one-click path as a bonus.

Limitations worth knowing before you rely on any of this

All URI-scheme approaches require a graphical desktop session — they do nothing in headless CI, SSH-only environments, or containers. Scheme registration is per-OS-user in some setups, so a fix applied for one account may not apply to another. And because neither GitHub's link format nor VSCodium's packaging guarantees are contractual, any rewrite-based trick can silently break after an update on either side. Verify after upgrades: open a PR page, click the link, and confirm the editor opens the expected folder with the expected branch in the Source Control view.

What to do next

First, test whether vscodium:// is registered on your machine using the terminal commands above. Second, adopt gh pr checkout plus codium . as your baseline workflow — it's the one combination with no unofficial dependencies. Third, if you want true one-click behavior, try a scheme-rewriting userscript, and re-verify it whenever GitHub or VSCodium updates. You'll get nearly all of the convenience of the official integration without pretending a native "Open in VSCodium" button exists.