The Bloat Is Load-Bearing

I spent an afternoon trying to fork a minimal terminal out of Warp. Short version: I gave up, and the reason is the useful part.

What I wanted was a quiet terminal: boots into a prompt, stays out of the way. No AI panel, no cloud sync, no telemetry, no notebooks, no blocks. Warp ships all of that before you type a single command. It’s also fast, good-looking, and open source now, so the plan looked easy. Fork it, strip what I don’t want, keep the core.

The parts I wanted to remove turned out to be holding up the parts I wanted to keep.

What I walked into

I expected a medium-sized app with some bloat bolted on the side. What I found was 71 separate crates and more than 3,000 Rust files, sitting on top of a bespoke UI framework Warp wrote themselves. It’s Flutter-inspired and has its own rules for how views are allowed to reference each other.

71

crates

3,000+

Rust files

1

bespoke UI framework

This is not a small program with features stapled on. It’s a large, coherent codebase, and the parts I thought of as bloat are part of the structure. I’m not a Rust expert, but you don’t need to be one to gauge the size of what you’re looking at.

Why I couldn’t just delete the AI

I went looking for the AI feature expecting a self-contained module I could remove. Instead it’s threaded through the app’s startup. It shares wiring with auth, which shares wiring with the cloud drive, which shares wiring with telemetry. Pull on one of them and the others move. These aren’t plugins you toggle off. They’re load-bearing.

Some of that wiring also points at services I can’t reach. Parts of the app phone home to Warp’s own servers. During setup, the bootstrap tried to reach an internal config repo and an internal cloud project, failed to get in, and carried on without them. As an outsider I get the open-source code. I don’t get the keys to the backing services it expects to talk to.

So “remove the bloat” was never going to be a delete. It’s a rewrite of things I didn’t build and don’t fully understand.

Licensing

One more constraint worth noting. Most of Warp is AGPL v3. Two of the UI crates are MIT, but the project as a whole is AGPL. That means anything I ship has to stay open under the same licence, even if I only ever serve it over a network. The Warp name and logo aren’t in the source either, so a public fork has to ship under a different name. None of this is a dealbreaker. It’s just one more thing you can’t change on your own.

Why not just use something like Ghostty or Alacritty?

Fair question, and the first one anyone asks.

By the time I’d finished listing everything I wanted gone (the AI, the sync, the account, the notebooks, the blocks), I wasn’t describing “Warp, but quiet” anymore. I was describing Ghostty. It’s fast, native, and has never once asked me to log in. Alacritty is more minimal still and has done the job for years. Neither has a cloud drive to tear out, because neither went looking for one.

So why fork at all? Curiosity, mostly. I liked Warp’s surface and assumed I could keep the look and skip the foundations. That was the mistake. The surface and the foundations are the same code.

The surface and the foundations are the same code.

What I took away

I don’t think Warp did anything wrong. The wiring that fought me is the same wiring that makes it feel like one product instead of forty separate tools. The agent understands your shell because it runs next to your shell. That closeness is the feature. It only looks like bloat from the outside, with a crowbar in your hand.

The lesson is about subtraction. Removing things from a codebase you don’t understand yet is harder than building from scratch, because you spend your time learning code you only mean to delete. A tool built around the things you don’t want is not going to become the tool you do want, however hard you pull on it.

The quiet terminal I set out to build was already installed. I just had to stop trying to build it.

I might still poke at the fork on a rainy weekend, for the education if nothing else.

Cheers!