Why

Why did I even bother creating this CLI?

You might be wondering—why even build this CLI when the official Zed for Windows is just around the corner (at the time of writing, the beta is about a month away)? Why not just contribute it directly to Zed itself?

This section explains why this CLI exists, and why I decided to build and release it as a standalone tool.

How it started

I first came across Zed in one of Theo’s videos around a year and a half ago. At the time, Zed wasn’t available for Windows—but the speed and responsiveness everyone talked about had me curious. I made a mental note: whenever it’s available on Windows, I’ll give it a shot.

Theo's Thumbnail for Zed's Video
Theo’s Thumbnail for Zed’s Video

April 2025

Fast forward to April 2025, turns out Zed was available on Windows… sort of. You could build it from source, or grab a prebuilt binary. I found Pirafrank’s unofficial Windows build and downloaded it. That version (Zed v0.176.3) ran instantly. The first thing I noticed? The performance.

To give you a sense of it: on my machine, Cursor used 2–2.3 GB of RAM for a large project without a dev server running. Zed handled the same project with a dev server running in under 300 MB. That kind of efficiency instantly won me over. I used it for all my work tasks over the next couple of weeks.

CLI Origins

At some point, I told a friend (who also uses a low-end Windows laptop) about Zed and got him to try it out. He downloaded the latest build (v0.181.0) and was impressed too. While I was showing him how it works–things like calling and project sharing, he asked:

“Does this have a CLI like VS Code? Can I open projects directly from the terminal?”

Tushar

Online

Dude, you have to try this new editor called Zed! The project sharing feature is incredible - we can literally work on the same code in real-time.
Plus, it has built-in voice calls and channels-no more switching between Slack and VS Code, or setting up Google Meet just to share your project with Live Share!
That sounds awesome! The performance you mentioned is really impressive too.
Does this have a CLI like VS Code? Can I open projects directly from the terminal?
Hmm... let me take a look at that.
Actually, I don't think it has a CLI yet. The 'Install CLI' button throws an error.
Yeah no worries, I don't use the terminal much anyway.
hmmm... yeah 🙂
Type a message...
The actual conversation that sparked everything

I hadn’t thought about it until then. I looked for a CLI, tried zed in the terminal, searched for an install option, and even tried the “Install CLI” button in the app—which threw a symlink error. In short: no CLI.

There was this short awkward pause on the call. He said something like, “Yeah no worries, I don’t use the terminal much anyway.” But that moment stuck with me.

The first version

Later that night, I hacked together a tiny .bat file, just 8 lines long–and added it to my PATH. It let me run zed . from the terminal to open the current directory. Basic, a bit sketchy, but it worked.

Cmd

@echo off
setlocal

set ZED_PATH="C:\Users\Samee\AppData\Local\Programs\Zed\zed.exe"

if "%~1"=="" (
    %ZED_PATH%
) else (
    %ZED_PATH% "%~1"
)

And that’s when I decided to go all in and build a proper CLI.

I had just finished working on SVGL for PowerToys and wasn’t building anything new at the time. I’d also never built a CLI tool before, so this felt like the perfect small but real-world project. I chose Go over Node/TypeScript mainly for better distribution and simplicity.

That was the beginning.

In short

I was using Zed. I recommended it to a friend. He pointed out a missing feature. I realized it mattered. And I decided to build it myself.

By the time I was done, the official Windows support was only a couple months away. But honestly, I had a great time building it. I learned Go, PowerShell, release automation, shimming, and how to distribute through Scoop and Chocolatey. It was my first time writing Go or PowerShell, and I ended up learning more than I expected.

But why not just contribute this to Zed itself?

I thought about it. But two things held me back:

  • The Zed codebase is in Rust. I’ve never written Rust. While I also hadn’t used Go before, it was easier for me to get started, especially with the recent TypeScript-to-Go trend influencing me.
  • Zed’s codebase is huge. My machine couldn’t handle the setup. Just installing the dependencies nearly filled up my C drive. Running or building the project locally wasn’t feasible.

So, while I’d love to contribute in the future, for now this CLI lives as a standalone tool. Maybe someday, with a better machine, I’ll take a deeper dive into the Zed core.

Thanks for reading. If you’ve made it this far, I appreciate it. Try the CLI–it’s lightweight, simple to install, and makes using Zed on Windows just a bit nicer.

I’ll soon write a technical deep-dive post about how the CLI works and the challenges I faced while building it.