Vscodium Extension Boundaries for Restricted Networks
Vscodium removes telemetry and uses Open VSX by default. Learn how to pin versions, sideload .vsix extensions, and verify gallery endpoints in restricted networks.
21 Aug 2026, 01:33 UTC

Problem and takeaway
A restricted network blocks Microsoft telemetry and the Visual Studio Marketplace, but developers still need a VS Code-compatible editor with extensions. Vscodium removes telemetry by default and uses the Open VSX Registry instead of Microsoft's gallery. The practical decision is to treat Vscodium as a separate supply chain: pre-vet extensions as .vsix files, pin versions, and verify the gallery endpoint before adopting it as a team standard.
Requirements
- No outbound telemetry to Microsoft endpoints during startup or extension use.
- Extension installation must work without direct access to the Visual Studio Marketplace.
- Updates must be predictable; unplanned major version changes are unacceptable in managed fleets.
- Extension host isolation must match VS Code behavior because Vscodium shares the core architecture.
Smallest suitable design
Use Vscodium with its default Open VSX Registry configuration. Add a local .vsix allowlist for extensions that are missing from Open VSX or must be pre-approved. Disable automatic extension updates and pin Vscodium itself to a specific release. This avoids relying on Microsoft's update service and keeps extension provenance under your control.
Example settings
In Vscodium user settings, verify or set gallery URLs and disable automatic checks. Exact setting names can vary by version; confirm them in your build before deploying.
{
"extensions.gallery": {
"serviceUrl": "https://open-vsx.org/vscode/gallery",
"itemUrl": "https://open-vsx.org/vscode/item"
},
"extensions.autoUpdate": false,
"extensions.autoCheckUpdates": false
}
Where to run: edit the user settings.json through Vscodium (File > Preferences > Settings) or directly in the settings file on the host. Permissions: ordinary user account for user-level settings. Risk: an incorrect serviceUrl silently breaks extension discovery without an error dialog.
Sideloading a pre-vetted extension
Download the .vsix from a trusted build or mirror, verify its checksum if one is published, then install it.
vscodium --install-extension /path/to/publisher.extension-name.vsix
Where to run: host shell or Vscodium integrated terminal. Permissions: ordinary user for a user-level installation; elevated privileges may be required for system-wide placement depending on the operating system. Expected check: the extension appears in the Extensions view and activates without a red error notification. Risk: a .vsix from an unverified publisher runs code in the extension host sandbox, so treat it like any other executable dependency.
Trust and data boundaries
Vscodium's update requests go to Vscodium's release channel, not Microsoft's update service. That changes signature trust: you are trusting Vscodium's release signing and build infrastructure rather than Microsoft's. The extension host, workspace trust model, and remote development boundaries are otherwise the same as VS Code because they share the core architecture. Telemetry-dependent extensions may call disabled APIs and fail silently, which means feature loss or missing error reports can look like application bugs rather than missing telemetry consent.
Operational checks
- Open Help > About (or the equivalent menu item) and confirm no Microsoft telemetry IDs are present.
- Inspect product.json in the Vscodium installation directory and confirm the update source references Vscodium rather than Microsoft.
- Open Extensions marketplace settings and confirm the gallery service points to Open VSX Registry.
- Search for a known Microsoft-only extension ID in the Extensions view. Absence, or an unofficial mirror, confirms marketplace divergence.
- Run a local network proxy during startup and confirm no outbound calls to Microsoft telemetry or marketplace telemetry endpoints appear in the traffic.
Practical way to check the result: install one extension from Open VSX and confirm it loads, then search for a Microsoft-only extension by ID and confirm it is unavailable or clearly labeled as a community mirror.
Failure modes
- Missing Microsoft-authored extensions. Open VSX may not include specific Microsoft extensions. Verify every required extension before adopting Vscodium as a standard.
- Silent degradation. Extensions that depend on VS Code telemetry APIs may disable features or error reporting without notifying the user.
- Version drift. Vscodium releases are not synchronized with Microsoft VS Code cadence. Pin versions in managed fleets to avoid unplanned major version changes.
- No vendor indemnity. Vscodium does not inherit Microsoft's extension support or indemnity terms; legal and compliance review is required for enterprise use.
Conditions that would change the design
- A required extension exists only in the Visual Studio Marketplace and cannot be redistributed as a .vsix. In that case, either sideload the .vsix manually or retain VS Code with telemetry disabled through policy.
- The enterprise contract requires Microsoft support or indemnity for the editor and extensions. Vscodium does not provide these terms.
- The network allows only a single allowlisted domain. You may need to proxy Open VSX or switch to a .vsix-only offline model.
Rollback
Because this configuration changes user settings and installed extensions, rollback means restoring the previous settings.json, removing sideloaded .vsix extensions, and re-enabling automatic updates if they were previously used. Test rollback in a non-production profile before applying it to managed devices.
Note: This draft describes well-established Vscodium behavior but requires verification against your specific build and network policy before production use. Confirm setting names, update URLs, and extension availability in your environment.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.