VSCodium Telemetry: What the Setting Actually Does (and What It Doesn't)

Start with the claim you actually need to defend

A privacy review rarely asks "is telemetry disabled?" It asks something harder: "show that this editor does not send usage data to a vendor." Those are different questions, and VSCodium answers them in different places. The setting most people reach for, telemetry.enableTelemetry, is the smaller half of the answer.

What VSCodium changes at build time

VSCodium is a community build of the same source tree as VS Code, with the Microsoft-branded build configuration and telemetry code paths removed before compilation. That is the substantive privacy decision: there is no vendor endpoint compiled in for the editor's own usage events to reach.

The practical consequence is that the editor's own telemetry setting becomes largely redundant. If the code that would send an event is not in the binary, a setting telling it to stay quiet has nothing to act on. Treat this as design intent rather than a guarantee for your specific release: the patch set is maintained per release in the project's build scripts, so if your review needs certainty, read the patch for the version you installed instead of assuming it is identical across versions. (Marked for review: confirm against the release you deploy.)

Why the setting still matters: extensions

Extensions do not ship with VSCodium; they come from a marketplace and run in a separate process. Well-behaved extensions ask the host whether telemetry is enabled through the extension API (the env.isTelemetryEnabled flag and the TelemetryLogger interface) before sending anything. When the host reports telemetry as off, those extensions go quiet rather than erroring.

That is the real job of the setting in a VSCodium install: it is a signal to third-party code, not a switch on the editor's own plumbing. Setting it explicitly means an extension that respects the API has no reason to fall back to a default-on path.

A concrete configuration

Run this in VSCodium itself, as your normal user account. No administrator or root access is required, because the file lives in your per-user configuration directory. That is also why the change survives application updates.

1. Open the Command Palette with Ctrl+Shift+P (Cmd+Shift+P on macOS).
2. Run Preferences: Open User Settings (JSON).
3. Add the keys below, keeping any existing entries intact.

{
  "telemetry.enableTelemetry": false,
  "telemetry.telemetryLevel": "off"
}

Which key your build honours depends on the version. telemetry.enableTelemetry is the older boolean; telemetry.telemetryLevel is the newer enumerated form, and in upstream VS Code the boolean was superseded. Setting both is harmless and covers either reading, but confirm which one your version documents before citing it in a compliance document.

Where the setting does not reach

This is the part that trips up teams who treat the setting as a firewall. It is not one.

• Extensions with their own network code. An extension can open an HTTP connection directly and never consult the telemetry API. The setting cannot stop that.
• Remote development. With SSH, Containers, or WSL, the editor UI runs locally but a server component runs on the remote host, which has its own settings and its own extension installs.
• Settings Sync and marketplace traffic. Signing in to sync or browsing extensions produces network requests unrelated to telemetry.

Comparison: what each control covers

Verifying without fooling yourself

Two checks are commonly suggested, and both prove less than people think.

The Output panel (Ctrl+Shift+U) has a channel selector. In a build with telemetry removed, a Telemetry channel may not exist at all. Its absence is consistent with the removal, but it is not proof that nothing left the machine.

Developer: Show Running Extensions lists installed extensions and their activation behaviour. It is a useful inventory of what is running, but it says nothing about network traffic. Do not present it as telemetry evidence.

If the review needs a defensible answer, observe the network. Run VSCodium behind a proxy you control, or capture traffic from the editor and extension host processes during a normal working session, and read the destinations. That is the only check that covers third-party code you did not write.

The trade-off, and one closing action

Turning telemetry off has a real cost: crash and error diagnostics that would otherwise reach an extension author no longer do, so bug reports get harder to act on. A reasonable team position is to disable it by default and document how to re-enable it temporarily when filing an upstream issue.

Concretely: set both keys in user settings, confirm which one your version documents, inventory your extensions, and, if the audit requires evidence, capture outbound traffic rather than pointing at a settings file. The setting is a useful signal to well-behaved extensions. It is not the thing that makes VSCodium private. The build is.