Vscodium Extension Registry Decision Guide: Default, Microsoft, Self‑Hosted, or Sideload

Problem: Where Should Vscodium Get Extensions?

Vscodium ships without Microsoft’s extension marketplace and points to Open VSX by default. Teams that need certain proprietary extensions, wish to control the catalog, or must stay air‑gapped face a choice: keep the default, repoint to Microsoft’s gallery, run a private Open VSX instance, or sideload VSIX packages. The decision hinges on compliance, catalog breadth, operational cost, and update reliability.

Decision & Constraints

Decision: Pick a registry strategy that balances licensing compliance, catalog completeness, and operational overhead. The default Open VSX is compliant but may lack needed extensions; Microsoft’s marketplace offers the largest catalog but violates the terms of service for non‑official VS Code products; a self‑hosted Open VSX gives control but requires maintenance; VSIX sideloading offers deterministic control but manual management.

Constraints:

• Microsoft’s Terms of Service prohibit using its marketplace with Vscodium.
• Extension compatibility depends on the VS Code engine version Vscodium is built from.
• Registry configuration lives in product.json and can be overwritten on upgrades.
• Self‑hosted Open VSX needs storage, publishing, and sync with upstream.

Compact Options Comparison

Option	Compliance	Catalog Size	Setup Effort	Update Reliability
Default Open VSX	✓ (Open source)	Large, but missing proprietary Microsoft extensions	None (out‑of‑the‑box)	Depends on upstream sync; extensions may lag Vscodium releases
Microsoft Marketplace	✗ (ToS violation)	Largest catalog, includes Pylance, C/C++ tooling, Remote packs	Configure product.json or use a proxy	High, but licensing risk
Self‑Hosted Open VSX	✓ (Controlled environment)	Same as Open VSX + custom extensions	High – server, sync, CI pipeline	Reliable if maintained, but lag risk if sync fails
VSIX Sideload	✓ (Manual)	Only extensions you sideload	Low – copy files or use CLI install	Very reliable, but manual version tracking required

Trade‑Offs Explained

Open VSX is the safest path but you must validate every required extension is available. Microsoft extensions often require license checks that fail outside official VS Code, so teams that rely on Pylance or Remote Development should consider official VS Code or open alternatives. A private Open VSX gives you the same catalog as the public registry plus the ability to host custom builds, but you must keep the mirror in sync. VSIX sideloading is deterministic and audit‑friendly; it works well for air‑gapped environments but you pay the price of manual updates.

Concrete Implementation: Repointing product.json

Vscodium reads the extension gallery endpoints from product.json under the extensionsGallery key. The file location varies by OS and packaging. Common paths:

• /usr/share/vscodium/resources/app/product.json (Debian/Ubuntu)
• /usr/share/vscodium/resources/app/product.json (Fedora/RPM)
• /Applications/VSCodium.app/Contents/Resources/app/product.json (macOS)
• $HOME/.local/share/vscodium/resources/app/product.json (Flatpak)

Below is a minimal product.json fragment that points Vscodium to a self‑hosted Open VSX instance:

{
  "extensionsGallery": {
    "serviceUrl": "https://open-vsx.org/api",
    "itemUrl": "https://open-vsx.org/vscode/item",
    "installUrl": "https://open-vsx.org/vscode/install"
  }
}

Replace the URLs with your own Open VSX server. If you want to point at Microsoft’s gallery (not recommended), use:

{
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "itemUrl": "https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery",
    "installUrl": "https://marketplace.visualstudio.com/_apis/public/gallery/extensioninstall"
  }
}

After editing, restart Vscodium. The change will be applied until the next upgrade; keep the configuration in a deployment script or package override to survive upgrades.

Validation Checklist

1. Inspect the file: Verify the extensionsGallery section contains the intended URLs.
2. Search in Extensions view: Open the Extensions side‑panel, type the name of a known extension, and confirm it resolves from the expected registry (the URL shown in the status bar or the extension’s details page).
3. CLI install test:

   # Replace publisher.name with a real extension
   codium --install-extension publisher.name
   # Verify the extension appears in the list
   codium --list-extensions | grep publisher.name
   

4. Smoke test the extension: Run a command the extension provides (e.g., python:formatDocument for Pylance) and ensure it executes without errors.

For a self‑hosted Open VSX, run the same steps after publishing the extension to your mirror to confirm it is reachable.

Limitations & Practical Tips

• Proprietary Microsoft extensions may refuse to run or may require license checks that only succeed in official VS Code; test each critical extension before deciding.
• Extension compatibility is tied to the VS Code engine version of the Vscodium build; pin extension versions in extensions.json if you need stability.
• Self‑hosting adds operational overhead: storage, CI for publishing, and keeping the mirror in sync with upstream Open VSX.
• VSIX sideloading is ideal for air‑gapped environments but requires manual tracking of new releases; consider a simple script that downloads the latest VSIX from a trusted source.
• Always verify the current Microsoft Marketplace ToS before pointing Vscodium at its endpoints.

Conclusion

Choosing the right extension registry for Vscodium is a trade‑off between compliance, catalog breadth, and operational complexity. The default Open VSX is the safest path; a self‑hosted Open VSX gives you control; Microsoft’s marketplace offers the largest catalog but violates licensing terms; and VSIX sideloading gives deterministic control at the cost of manual updates. Use the product.json snippet above to reconfigure Vscodium, and follow the validation checklist to ensure your choice works in practice.