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.

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
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.