Engineering a Telemetry-Free Binary: The VSCodium Build Architecture
An architectural deep dive into how VSCodium removes proprietary telemetry from the VS Code source to provide a fully open-source binary distribution.
14 Sept 2025, 02:43 UTC

The Problem: Proprietary Bloat in Open Source Binaries
Visual Studio Code is distributed by Microsoft under a proprietary license, despite being built from the MIT-licensed vscode repository. This distribution includes telemetry—automated data collection about usage and crashes—and proprietary binaries that are not present in the raw source code. For engineers requiring a strict audit trail of data egress or a fully open-source toolchain, the official binary is unsuitable.
The core engineering challenge is not just compiling the source, but systematically stripping the telemetry hooks and proprietary components that are injected during Microsoft's build process, while maintaining a functional IDE.
The Smallest Suitable Design
VSCodium implements a build-time transformation layer rather than a runtime patch. The design focuses on three primary requirements: automation of the MIT source fetch, identification of telemetry modules, and the removal of proprietary signing.
The Build Pipeline
The architecture relies on a series of scripts that operate on the raw source before the final bundling phase. Instead of modifying the source code manually—which would make upstream updates impossible—VSCodium uses a pattern-matching approach to identify and exclude specific modules.
- Source Acquisition: Clones the official
microsoft/vscoderepository. - Telemetry Stripping: Scans for modules associated with
telemetryandtracking. These are replaced with \"no-op\" (no operation) functions that mimic the original API signatures but perform no actual data transmission. - Binary Packaging: Bundles the resulting code into a platform-specific executable without the proprietary Microsoft signatures.
Trust and Data Boundaries
The trust boundary in VSCodium is shifted from the provider (Microsoft) to the process (the build script). By utilizing the MIT-licensed source, the boundary is defined by what is explicitly included in the final package.
| Component | Official VS Code | VSCodium |
|---|---|---|
| Source Code | MIT License | MIT License |
| Telemetry Binaries | Included/Proprietary | Removed/No-op |
| Marketplace Access | Microsoft Marketplace | Open VSX Registry |
| Binary Signature | Microsoft Signed | Community/VSCodium Signed |
To maintain this boundary, VSCodium avoids the official Microsoft Marketplace. The Marketplace Terms of Service restrict the use of the gallery to official Microsoft products; therefore, VSCodium connects to Open VSX, an open-source alternative, to ensure no proprietary data‑sharing agreements are implicitly accepted via the extension manager.
Operational Checks and Verification
To verify that the telemetry removal was successful, an engineer can inspect the installed modules or monitor network traffic during the first launch.
Verification via Module Inspection
Run the following command in a terminal (Linux/macOS) to check for the presence of telemetry‑related strings in the binary. This requires grep and access to the installation directory:
# Replace [path-to-vscodium] with your actual installation path
grep -r \"telemetry\" [path-to-vscodium]/resources/app/out/vs
Expected Result: You should see references to telemetry functions, but they should be mapped to empty functions or disabled flags in the configuration, rather than active network endpoints.
Network Egress Check
Using a tool like Wireshark or tcpdump, monitor outgoing traffic on ports 80 and 443 during startup. A standard VS Code installation will typically attempt to contact dc.services.visualstudio.com. A successful VSCodium build will show no traffic to these specific Microsoft telemetry endpoints.
Failure Modes and Design Shifts
The primary failure mode is Upstream Drift. Because VSCodium relies on pattern matching to strip telemetry, any significant refactor by Microsoft to the telemetry module names or directory structures can break the build script.
- Build Breakage: If a telemetry module is renamed, the script may fail to find it, potentially allowing a proprietary component to leak into the build or causing a compilation error.
- Extension Incompatibility: Some extensions are hard‑coded to require the official Microsoft binary (e.g., certain C# or Live Share components). This is a limitation of the design; supporting these would require violating the telemetry‑free requirement.
A shift in the design would be necessary if Microsoft moved telemetry logic into a pre‑compiled binary blob provided as a dependency. In that scenario, simple source‑stripping would be insufficient, and the project would need to implement a runtime shim or a binary patcher to intercept the API calls.
Rollback and State Changes
Since VSCodium is a standalone installation, the only state change is the installation of the binary. To rollback to the official distribution, uninstall VSCodium and delete the ~/.config/VSCodium (or equivalent) directory to prevent configuration conflicts before installing the official VS Code binary.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.