VSCodium Is a Supply-Chain Decision, Not Just a Telemetry Toggle

A teammate installs VSCodium, opens the Extensions view, searches for the linter everyone else uses, and finds nothing — or finds a different publisher with a similar name. That moment is where most "VSCodium vs VS Code" discussions should start, because the real difference between the two editors is not the icon or the telemetry toggle. It is which extension gallery you are trusting, and who is responsible for what comes out of it.

The thesis of this post: adopting VSCodium is a governance and supply-chain choice. You get a cleaner licensing story and quieter defaults, and in exchange you take on explicit responsibility for extension provenance, availability, and updates.

What VSCodium actually is

Microsoft publishes the VS Code source code under the MIT license, but the binaries you download from Microsoft are built with additional product configuration: branding, an update service, telemetry defaults, and a pointer to the Microsoft Visual Studio Marketplace. VSCodium is a community build of that same MIT-licensed source with Microsoft's proprietary bits left out. The editor itself — the workbench, the language features, the debugging model — is the same code.

Two consequences follow. First, "telemetry is off by default" describes the editor's own settings, not a guarantee about everything running inside it. Extensions are separate programs with their own terms; an extension can collect its own data if its license allows it, regardless of which build of the editor hosts it. Second, the interesting differences live in a configuration file called product.json, not in the UI. That file controls the extension gallery endpoint, the update service, and branding, which means two installs showing the same version number can behave differently.

The marketplace is the real fork in the road

VSCodium commonly points its Extensions view at Open VSX, an open, vendor-neutral extension registry, rather than the Microsoft Marketplace. Microsoft's marketplace terms restrict official use of that gallery to Microsoft's own builds, which is why the community build doesn't ship pointing at it.

This changes your day-to-day in three ways:

• Coverage. Some extensions are published to both registries; some only to one. Popular open-source extensions are often on Open VSX, but availability is per-extension and changes over time.
• Freshness. Even when an extension exists in both places, the Open VSX copy may lag behind the Marketplace version, depending on how the publisher releases.
• Naming collisions. An identifier that exists in both registries is not automatically the same artifact from the same publisher. Verify the publisher field, not just the name.

A worked example: onboarding one extension

Say your team standardizes on a language server extension and a new writer joins with VSCodium. A defensible onboarding flow looks like this:

1. Confirm the gallery. Open the About dialog (or inspect the install's product.json) and check the configured extension gallery and update service before assuming anything. Do this on each OS your team uses; packaging differs across Windows, macOS, and Linux.
2. Search in a clean profile. Run codium --profile-temp (or create a fresh profile from the UI) so existing settings don't mask the result. Search for the extension by its full identifier, e.g. publisher.name, not a fuzzy keyword.
3. Verify before installing. Check the publisher, exact identifier, and version against what the rest of the team runs. If the version differs, decide whether that matters for your linting or formatting rules — version drift in a formatter is a classic source of noisy diffs.
4. Install, reload, and exercise it. Open a real project file and confirm the feature actually works (diagnostics appear, formatting applies), not just that the extension shows "installed."
5. Pin it. Record the approved identifier and version in your team docs or a workspace .vscode/extensions.json recommendation list.

If the extension only exists on the Microsoft Marketplace, you have three honest options: find an alternative on Open VSX, ask the publisher to publish to Open VSX (many will), or use Microsoft's build for the people who need that extension. Side-loading VSIX files downloaded from the Marketplace sits in a licensing gray area governed by the Marketplace terms — treat that as a legal question, not a technical workaround.

The trade-off you're accepting

VSCodium gives you MIT-licensed binaries, no Microsoft branding, and quieter defaults. What you give up is the assumption that "the extension ecosystem" is one thing. You now own a small amount of ongoing work: tracking which registry each approved extension comes from, noticing when versions diverge, and having a fallback plan for Marketplace-only tools. For a solo developer this is a minor annoyance. For a team, it's a policy decision that belongs in writing.

Also note that everything here is version-sensitive. Gallery endpoints, packaging, and extension availability change, so verify against the build you actually install rather than trusting any article — including this one — as current.

A practical starting point

If you're evaluating VSCodium for a team, do this in one afternoon: install it on each OS you support, check product.json for the gallery and update endpoints, then attempt to install your five most critical extensions in clean profiles and record publisher, identifier, and version for each. Whatever survives that list is your supported set; whatever doesn't is your documented exception process. That one page of notes is worth more than any feature comparison table.