VSCodium: build scripts for Microsoft's own repository, and telemetry switched off by default

Not a fork: this repository builds Microsoft's and publishes the output

The sentence at the top of the README is the whole project in one line. This is not a fork. It is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration.

The mechanism is described in the section on why this exists. The build scripts in this repository clone Microsoft's vscode repository, run the build commands, and upload the resulting binaries to the GitHub releases. That is the entire pipeline, and it is why there is no editor source code here to read.

The tree is consistent with that. There is a build directory and a build script, scripts for preparing the source, the assets, the checksums and the version, a script for updating the upstream repository, a script for undoing telemetry, a patches directory, a product configuration file, an upstream directory, and a release script. It is a build system for someone else's repository, which is a different maintenance commitment from a fork.

The consequence for a reader is that the interesting questions are about the build, not about the editor. What is in the release is Microsoft's code, and what VSCodium changes is the packaging and the defaults.

One product configuration is the whole licence difference

The why section is built around a quotation from a Visual Studio Code maintainer, and the quotation explains the mechanism precisely.

When Microsoft builds Visual Studio Code, they clone the vscode repository, lay down a customised product configuration that has Microsoft specific functionality including telemetry, a gallery and a logo, and then produce a build released under their licence. When you clone and build from the vscode repository, none of those endpoints are configured in the default configuration. You therefore generate a clean build, without the Microsoft customisations, which is by default licensed under the MIT licence.

So the difference between the two binaries is a configuration file and the endpoints it points at. The repository root carries that file, alongside two announcement manifests for built-in and additional announcements, which suggests the default experience is also curated here rather than inherited.

And the outcome is stated in one sentence with the emphasis the project wants: the binaries are licensed under the MIT licence, and telemetry is disabled. There is a script in the root whose name is the inverse of that claim, one to undo telemetry, which is the kind of file you only need if the build produces something that still reports.

Stable and insiders are separate packages on every platform

Two release channels run in parallel, and every installation route publishes both, which is the first thing to get right. On macOS, two Homebrew casks, one per channel:

# stable
brew install --cask vscodium

# insiders
brew install --cask vscodium@insiders

On Windows with the Windows package manager there are two package identifiers, and with Chocolatey there are two package names, and with Scoop the README shows the stable route. On Linux the Snap Store has the project published under a different name altogether, and the Arch user repository carries four separate packages.

The naming is not consistent across platforms, which is a real cost when you write an installation document. The Snap package is called something other than VSCodium, the insiders cask carries a suffix, and the Arch packages are distinguished by a suffix and by a variant. A script that installs VSCodium has to know which platform it is on.

The two channels are also published from two different release pages, one for stable and one for insiders, so tracking them means watching two feeds.

Arch offers a system-Electron variant, and it trades isolation for disk space

The Arch section is the most detailed of the installation instructions, and it is worth reading because it shows the decisions a self-hoster actually faces.

There is a binary package for stable, a binary package for insiders, a package that makes VSCodium use the Electron runtime installed system-wide, and a package for people who want to compile from source themselves. Four packages, each with a named maintainer.

The system-wide Electron variant is the interesting one. The stated benefit is saving disk space, because the editor does not carry its own copy of the runtime. The cost is not stated in the README and follows from the design: you are running a VSCodium build against whatever Electron your distribution ships, so the editor's behaviour now depends on another package's release cycle, and a runtime upgrade can change the editor without VSCodium changing at all.

That is a reasonable trade on a machine where disk is tight and a poor one on a machine where you want the editor's behaviour to be reproducible from a single pinned artefact.

Linux package installs point at a third party's repository, and its tracker

For Linux distributions with a package manager, the README does not offer a first-party repository. It points at one set up by a named maintainer, with instructions for three package managers, hosted on a forge other than GitHub.

What matters is the sentence that follows. Any issues installing VSCodium using your package manager should be directed to that repository's issue tracker.

So the support boundary is explicit. Installation problems through that repository are not this project's problem and are not upstream's; they belong to the person who runs the repository. And a repository on a different host, maintained by one person, is a supply chain decision as much as an installation convenience.

The alternative the README does offer is the downloads on the releases page, in three formats, for stable and for insiders, which is the path with the fewest moving parts between you and the build the project published.

The build job is a set of CI checks, and none of them compiles the editor

The task runner in the repository root is short, and it is the most surprising file in a project that exists to build a large editor.

There is a lint recipe that runs a security scanner over the repository, and a fix variant for it. There is an update recipe for the action dependencies, with a minimum age filter of seven days. There are two recipes for the editor configuration format, one to check it and one to fix it, both taking the verbose flag and the same ignore file.

That is four recipes, and none of them builds VS Code. The compilation lives in the shell scripts in the root and in the upstream repository's own build system; this task runner covers the things that go wrong around a build, which are the action references that drift, the configuration formatting, and the security posture of the workflow files themselves.

The seven day minimum age on the update recipe is a supply chain measure rather than a formatting one. A newly published action is not adopted immediately, which means a compromised action has to sit for a week before this project will pull it in.

Snap and Flatpak have different names, and one of them is not a sandbox

Two of the Linux routes are worth separating because they behave differently.

The Snap is published in the Snap Store under a different name from the project, and it is installed with the classic flag, which is the mode that gives the package access to the host's home directory and other resources rather than confining it. That is a deliberate choice for an editor that needs your files, and it also means the snap is not a strong isolation boundary.

The Flatpak, by contrast, is a real sandbox with its own application identifier, and the README gives both the install and the run command. The trade is the usual one: better confinement, and a version of the editor that runs against a contained filesystem, so anything that reaches outside the sandbox needs an explicit port.

The Snap and the Flatpak also have different maintenance homes. The Snap is credited to a community group, the Arch packages to individual maintainers, and the Flatpak to a build repository on a different forge again. Four installation routes, four sets of maintainers, and no statement in the README about which of them tracks upstream fastest.

Editorial conclusion

Use VSCodium if you want the VS Code interface under a free licence with no telemetry, and you are comfortable that you will be following a build of upstream rather than tracking a fork. Do not use it expecting Microsoft's marketplace, branded first-run experience, or the official support path, since those are exactly the product customisations this project removes. Before you install: pick a channel, since stable and insiders are separate packages on every platform listed; on Arch, note the difference between the binary package and the one that reuses a system-wide Electron runtime, which saves disk space at the cost of being bound to your distribution's Electron version; and on Linux with a package manager, remember that the apt, dnf and zypper repository is maintained by a third party and that install issues belong in that repository's tracker rather than upstream.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes