VSCodium marketplace configuration limits for Microsoft-dependent extensions

Direct answers

1. Subset routing: No. VSCodium uses a single gallery endpoint compiled into product.json at build time. There is no documented mechanism to send only some extensions to the Microsoft Marketplace while keeping Open VSX for the rest. Pointing VSCodium at the Microsoft endpoint is also not policy-compliant under Microsoft's Visual Studio Marketplace Terms of Use (Section 1.b, requires verification), which restrict that marketplace to Microsoft's official VS Code products.
2. Version drift: No automated synchronization exists between Open VSX and the Microsoft Marketplace. Publishers must opt in to push updates to both registries, typically with separate tooling, so Open VSX releases can lag by days or weeks. Teams should inventory shared extensions, compare versions against publisher release notes, and treat Open VSX as a potentially delayed source for security patches.
3. Runtime override: No. The marketplace URLs in product.json are baked into the release binary. Standard VSCodium builds do not support per-user, per-workspace, or environment-variable overrides at runtime. Changing the endpoint requires rebuilding VSCodium from source.

Likely explanation versus facts to confirm

The likely design reason is isolation: VSCodium removes Microsoft services and telemetry, so a single community registry avoids mixed-registry dependency resolution. The following items require verification against your deployed build before they are treated as confirmed:

• Open VSX does not host Microsoft-proprietary extensions such as Pylance, Live Share, or Azure Account; no VSCodium configuration change can make them available there.
• Manual VSIX installation bypasses automatic updates, so each extension must be tracked and patched independently where licensing permits.
• Rebuilding VSCodium from source for every update cycle adds operational overhead and can delay upstream security fixes.

Steps for this case

1. Run the read-only command codium --list-extensions --show-versions and record each extension's publisher and version.
2. Classify extensions as Open VSX only, both registries, or Microsoft-only.
3. For Microsoft-only extensions, choose a policy-compliant path: use official VS Code for that workload, substitute an open-source alternative such as Pyright for Pylance, or manually install publisher VSIX files and accept manual update tracking.
4. For extensions published to both registries, subscribe to publisher release notes and verify Open VSX lag before approving security updates.

Missing diagnostic detail

Are your VSCodium installations managed centrally through package repositories, or by individual users? This determines whether rebuilding from source is practical or whether standardizing on official VS Code for Microsoft-dependent workloads is the better option.

Verification required before publication

This is a conservative draft. Confirm the following before release: the exact product.json gallery fields in your VSCodium version, the current Microsoft Marketplace Terms of Use Section 1.b, Open VSX absence of the proprietary extensions you need, and that no runtime environment variable overrides gallery URLs in your build.