Your code editor sees everything. Every file you open. Every line you write. Every project you work on. Every search you run. Every terminal command you execute. If any tool on your machine has a complete picture of your work, it is your code editor.

Most developers are handing that picture to Microsoft.

The Chromium and VS Code Problem

VS Code is not just a text editor. It is an Electron application. Electron is a framework that runs a full Chromium browser engine to render a desktop interface. When you open VS Code, you are running a Google-built browser engine wrapped in a Microsoft-built application. Two of the largest advertising and data collection companies on earth have their DNA in the tool you write code with every day.

Microsoft takes the open source VS Code codebase, adds proprietary telemetry, wraps it in a proprietary license, connects it to their extension marketplace, and ships it as a free product. Free as in you are the product. The editor reports your usage patterns, extension installs, error data, performance metrics, and feature usage to Microsoft servers. By default. Every time you launch it.

Then there is the Chromium layer underneath. Electron bundles an entire browser engine to render what is fundamentally a text editor. That engine consumes hundreds of megabytes of RAM before you open a single file. It was designed to render web pages, not edit code. The performance ceiling of every Electron-based editor is determined by how fast a web browser can draw text. That is a fundamentally wrong foundation for a development tool.

Why VSCodium and Ungoogled Chromium Are Cosmetic Fixes

We have written about both VSCodium and ungoogled Chromium on this blog. Both are real projects doing real work. Both are improvements over the defaults. Neither solves the actual problem.

VSCodium strips Microsoft telemetry from VS Code. That is valuable. But it is still Electron. Still Chromium. Still a web browser pretending to be a desktop application. You removed Microsoft from the equation but left Google’s rendering engine running underneath. The architecture is the same. The resource consumption is the same. The fundamental design decision of using a browser engine to edit text is unchanged. You patched the surveillance but kept the bloat.

Ungoogled Chromium does the same thing on the browser side. It removes Google services from Chromium. Legitimate work. But it is still Chromium. Still Google’s engine. Still a codebase that Google controls, that Google steers, that Google makes architectural decisions about based on Google’s interests. Every browser built on Chromium, no matter how many Google services it removes, is downstream of Google’s engineering choices. If Google decides to change how extensions work, every Chromium fork deals with it. If Google deprecates a web API, every Chromium fork inherits that decision. Removing the telemetry does not remove the dependency.

The pattern with both tools is the same. Take something built by a surveillance company. Remove the surveillance. Ship it and call it clean. But the foundation was never clean. It was designed from the start to serve the interests of the company that built it. Stripping the tracking is a patch. The architecture was never built for you.

What to Look For in a Clean Editor

If you are serious about controlling your tools, here is what a code editor should provide:

  • No telemetry by default. The editor should not phone home unless you explicitly opt in. Not an opt-out toggle buried in settings. No telemetry in the binary unless you turn it on.
  • Open source. The entire application. Not an open source base with proprietary additions layered on top. Not open source with a CLA that lets the company relicense your contributions. Actually open source. Readable, buildable, auditable.
  • No Electron. A code editor should not need a browser engine to render text. Native performance matters. Memory consumption matters. Startup time matters. These are not luxuries. They are the baseline.
  • No vendor lock-in. Your settings, your extensions, your workflow should not depend on one company’s ecosystem. If the company goes under, gets acquired, or changes direction, your editor should still work.
  • Auditable network behavior. You should be able to run a packet capture on your machine and see exactly zero outbound connections from your editor when you are not explicitly using an online feature. If you cannot verify it yourself, the promise is meaningless.

Zed

Zed is a code editor built by the people who created Atom, the editor that GitHub built before Microsoft acquired GitHub and killed Atom in favor of VS Code. They watched the editor they built get absorbed into Microsoft’s ecosystem and shut down. Then they started over.

Zed is not a fork. It is not a wrapper. It is not a reskin of someone else’s project. It is written from scratch in Rust. Native GPU rendering through their own framework called GPUI. No Electron. No Chromium. No web technologies in the rendering pipeline. The editor talks directly to your GPU to draw text. The difference in performance is not incremental. It is a different category.

Startup is near-instant. Memory consumption is a fraction of VS Code. File operations are fast because they are not going through a JavaScript runtime and a browser engine to reach the filesystem. The editor feels like a tool built for the machine it runs on, because it is.

Zed is open source under a dual GPL/AGPL license. The code is on GitHub. You can read it. You can build it. You can audit exactly what it does on your machine. There is no proprietary layer on top. There is no "community edition" with missing features. The editor you download is the editor they develop.

Disable Telemetry on First Launch

Zed does include optional telemetry and crash reporting. Unlike VS Code, it is straightforward to disable and the editor respects the setting. On first launch, open your settings file:

macOS: Cmd+, or Zed > Settings > Open Settings

Linux: Ctrl+,

Add this block to your settings.json:

{
  "telemetry": {
    "diagnostics": false,
    "metrics": false
  }
}

That is it. Two settings. Diagnostics controls crash reporting. Metrics controls usage analytics. Set both to false and Zed sends nothing. No buried toggles. No trust required that a binary you did not compile will honor a setting. The code that checks these values is open source. You can read the implementation yourself.

Verify It Yourself

Do not take anyone’s word for it. Including ours. Run your own network monitoring and see what Zed actually does on your machine.

On macOS, open a terminal and run:

# Watch all network connections made by Zed
sudo lsof -i -n -P | grep -i zed

Or for continuous monitoring:

# Log all DNS lookups from Zed
sudo tcpdump -i any -n port 53 2>/dev/null | grep --line-buffered zed

With telemetry disabled and no collaborative features active, Zed should make zero outbound connections while you edit code. If you see connections you do not expect, you have the source code to figure out why. That is the difference between a tool you control and a tool that controls you.

For a more thorough audit, use a tool like Little Snitch or Lulu on macOS. These are application-level firewalls that show every outbound connection attempt from every process on your machine. Run Zed with telemetry disabled and watch. You should see nothing. If you see something, block it and investigate.

The Cross-Platform Path

Zed runs on macOS and Linux. The Linux version reached stable in early 2025 and is actively developed. Same editor. Same configuration. Same settings file. Your settings.json and keybindings work on both platforms.

This matters because the endgame for a lot of developers on this blog is Linux. If you are moving off Apple or Microsoft platforms, your editor should come with you. Zed does. Your configuration is a JSON file in a known location. Copy it to a new machine and you have your editor. No account sync. No cloud service. No dependency on a company’s infrastructure to move your own settings to your own machine.

On Linux, install via the official script:

curl -f https://zed.dev/install.sh | sh

Or through your package manager if your distribution has packaged it. The settings file lives at ~/.config/zed/settings.json. Same format. Same options. Same telemetry block to add on first launch.

The Principle

The tools you build with should not be built against you. VS Code is a surveillance platform that edits text. VSCodium removes the surveillance but keeps the architecture that was designed for it. Every Electron-based editor is a browser engine pretending to be a development tool, burning resources to render what should be the lightest interface on your machine.

Zed is what a code editor looks like when you start over without the ad-tech DNA. Native. Fast. Open source. No telemetry by default. Verifiable on your own network. Portable across the platforms that matter.

Your editor sees every line of code you write. Make sure it answers to you and nobody else.