Question
Open VSX Gallery transition and proprietary extension compatibility
Rey Maple
0 reputation · 27 Nov 2020, 13:57 UTC
27K views1
Loading…
0 reputation · 27 Nov 2020, 13:57 UTC
VSCodium replaces the default Microsoft Marketplace with the Open VSX registry to maintain a telemetry‑free environment. This change alters how the editor resolves extension IDs and handles updates for plugins that are not mirrored on the open‑source registry.
Certain extensions published by Microsoft are licensed exclusively for official VS Code builds and may not be available or fully functional within VSCodium. This creates a compatibility boundary when migrating configurations or attempting to synchronize a workspace across different distributions.
When a user transitions from VS Code to VSCodium, the product.json configuration determines the gallery endpoint, but the behavior of extensions relying on proprietary Microsoft APIs remains inconsistent.
32275 reputation · 27 Nov 2020, 20:26 UTC
VSCodium ships with the Open VSX Registry as the default gallery and does not provide a built-in, selective gallery mix that keeps the telemetry-free build while automatically pulling proprietary Marketplace-only extensions. You can install a proprietary extension manually as a .vsix in VSCodium without adding telemetry to the editor itself, but pointing VSCodium back to the Microsoft Marketplace via extensions.gallery.serviceUrl re-introduces connections to Microsoft services and is discouraged by the VSCodium project.
Extensions that target a specific distribution ID or check for an official VS Code build will install in VSCodium but may refuse to activate. The editor does not block installation based on distribution ID; activation and licensing checks are performed by the extension itself.
vscodiumproduct.json. The default build is telemetry-free and points to Open VSX.Compatibility is technical rather than functional. A proprietary extension built against the VS Code extension API will generally run in VSCodium if it is installed as a .vsix or from a gallery that hosts it. Licensing, update channels and marketplace authentication remain publisher controlled. Some Microsoft-published extensions check vscode.env.appName / app root and deliberately deactivate on non-official builds such as VSCodium.
Mixing galleries can cause duplicate extension IDs and conflicting update channels. Open VSX and Marketplace have independent review and signing processes; a version available in one may lag or differ from the other.
Extensions: Install from VSIX in VSCodium and manage updates manually.One missing diagnostic detail that changes the recommendation: which specific extension ID and publisher you need. Microsoft-published extensions such as GitHub Copilot have explicit distribution checks and will not activate in VSCodium even from a .vsix, whereas third-party proprietary extensions often work once installed manually.
Use comments to ask for clarification. Post a solution as an answer.
4,940 reputation · 27 Nov 2020, 21:45 UTC
Built-in Settings Sync relies on Microsoft's proprietary authentication components, which are absent from VSCodium builds, so cross-distribution configuration sync typically falls back to manually copying the user profile or using a third-party sync extension.
The most common functional loss is the Remote Development family (Remote-SSH, WSL, Dev Containers): Microsoft-published, Marketplace-only, and licensed for official builds. Community forks such as Open Remote - SSH are published on Open VSX and activate in VSCodium, usually the least-friction path for remote workflows.
Extensions installed from a .vsix are also effectively pinned: the updater only queries the configured gallery, so a publisher/ID with no Open VSX listing receives no automatic updates. Plan a manual update cadence for those.
This reflects current VSCodium builds; verify on your install via the Command Palette's Settings Sync commands and by searching the extension ID on open-vsx.org.