libghostty: Why Agent Tools Build on Ghostty (and I Build a Terminal)

Same engine?

This week JetBrains announced that the terminal in their IDEs now runs on a new engine. Agent tools like cmux, Supacode and Calyx have one thing in common with that new terminal: the same core, libghostty. So does every agent tool run on Ghostty now? Not quite. Today I'll show you what libghostty is, and who really uses it. Then we build our own terminal window on it, in about a hundred and eighty lines of C. Moin, I'm Mathias, and this is Elbcasts. Last time, GPT six point one Terra and Kimi K three point one Pro got the same Rails ticket. Today we go one layer down, into the thing every coding agent talks to: the terminal.

What libghostty is

Ghostty is Mitchell Hashimoto's terminal. In September twenty twenty-five, he announced libghostty: Ghostty's core as a library that any app can embed. The first piece you can use today is libghostty-vt. It parses escape sequences and keeps track of the terminal state: the cursor, colors and styles, the scrollback, and the alternate screen. It has a C and a Zig API, it runs on macOS, Linux, Windows and WebAssembly, and it needs no other libraries. Built without SIMD, it doesn't even need libc. What it doesn't do is windows, fonts or GPU rendering. You bring those.

Stable core, moving API

The Ghostty README is honest about where it stands: The functionality is extremely stable, but the API signatures are still in flux. There's no version tag yet. Mitchell's argument for the whole thing goes like this. Terminal emulation is not the core business of JetBrains, VS Code or Vercel. Yet they all need a terminal, and most of those implementations are incomplete, buggy and slow. One shared, correct core beats that.

JetBrains switches

So who actually uses it? Start with JetBrains. In the twenty twenty-six point three builds, their IDEs use libghostty in place of JediTerm. libghostty parses the output and holds the state, and the IDE still does the drawing. The main win for us is the Kitty keyboard protocol. Shift Enter in Claude Code or Codex finally starts a new line, instead of sending half your prompt. JetBrains says the new engine handles almost fifty control sequences that JediTerm ignored or misread.

Who else uses it

Then there are the agent workspaces. cmux, a macOS terminal built for AI coding agents, has almost twenty-nine thousand stars on GitHub. Supacode and Calyx are native macOS apps for running agents, too. These three embed Ghostty's full library, GPU renderer included, not just libghostty-vt. Neovim has an open pull request to replace libvterm with libghostty-vt. Mitchell says it's verbally accepted, but it's not merged yet. Then there's Emacs with Ghostel, Coder's Boo, a multiplexer, and bindings for Go, Rust, dot NET and Swift. The awesome-libghostty list has a hundred and thirty-five projects, and thirty-five of them are AI agent tools, most of them for macOS.

Hype check

Now the hype check. Claude Code and Codex don't embed libghostty. They are programs that run inside a terminal. OpenCode is the exception: its app uses libghostty-vt, compiled to WebAssembly, for its terminal panes. VS Code still ships xterm dot js, and Zed uses Alacritty's terminal crate. So the accurate claim is this: if you build a new agent workspace or terminal today, libghostty is the default choice.

Why everyone picks it

Why does everyone pick it? First, correctness. Agent TUIs use modern protocols: the Kitty keyboard protocol, theme change notifications, and synchronized output. libghostty-vt supports all three. Second, it's embeddable: a small C API, no dependencies, and bindings for almost every language. Third, it's proven. It's the same code that already runs Ghostty itself, and it scales. Mitchell says a single empty terminal now takes ninety percent less memory. And he has run ten thousand active terminals on a Linux server with four cores and eight gigabytes of RAM.

Demo: setup

Now the demo. You need Zig zero point one seven. Even for a C project, Ghostty uses Zig's build system to compile the library. And we pin Ghostty to one commit, because the API still changes. In build dot zig, we link libghostty-vt from that dependency, plus SDL two for the window, and SDL TTF for the font. Two things cost me time on macOS. Only the static library exists as an artifact here. And with pkg-config, SDL gets linked twice, and the program won't even start.

Demo: a shell in a pty

A terminal has two halves. The shell talks to a pseudo-terminal, and we read the other end. One call, fork P T Y, gives us both. The child becomes a login shell, like in any real terminal, and we keep a file descriptor that never blocks.

Demo: the terminal

Now libghostty. There are three kinds of objects: the terminal itself, a render state that works as a snapshot for drawing, and iterators over rows and cells. One callback matters here. When the shell asks where the cursor is, libghostty writes the answer back through us. Every frame, we read whatever the shell wrote, and hand it to libghostty. This one line replaces thousands of lines of escape code parsing.

Demo: drawing cells

Then we draw. We take a snapshot of the terminal. If nothing changed, we skip the frame. Otherwise we fetch the colors, and clear the window with the background. Now we walk through the rows and cells. libghostty has already resolved the palette colors for us. If a cell has no color of its own, we keep the default. One thing we do by hand: inverse text, where foreground and background swap. That's what top uses for its sort column. Last, the text of the cell. A cell can hold a whole grapheme cluster, so libghostty gives us its length, and then the code points. We draw the first one. And when the frame is done, we mark the snapshot clean.

Demo: keys out

And the keys. Typed text goes straight to the shell. Enter, Backspace, the arrow keys, and Control C, I map by hand. A real terminal would use libghostty's key encoder here.

Demo: running it

Time to run it, with zig build run. The first build takes about forty seconds on my machine, because Zig compiles libghostty and its dependencies. After a change, it's about a second. And there's our prompt. L S with colors works. Here's true color, a twenty-four-bit orange. Umlauts work too: Moin, äöü. Now top. That's the alternate screen with full-screen redraws, and the column it sorts by is inverted. I wrote none of that logic. About a hundred and eighty lines. The emulation is libghostty. Everything else is us. One more test: Claude Code, in our own window. The banner, the colors, the input box, the spinner, it all just works. Look closely, though. Those little boxes are symbols our font doesn't have. Font fallback is our job, not libghostty's. And since we skipped the key encoder, Shift Enter sends the prompt here, instead of starting a new line. That's exactly what JetBrains fixed with the Kitty keyboard protocol.

Honest evaluation

My honest evaluation. On the plus side, the emulation is correct and modern right away. The C API is small and readable, the examples are excellent, and there are bindings for almost every language. On the minus side, there's no version tag yet, and the API still changes, so pin a commit. You need Zig in your build, even for C. Rendering, fonts, font fallback, emoji, selection and IME input are all your job, and that's where the real work in a terminal is. And the agent terminal boom is very macOS-heavy. Not everyone is sold, either. Under the Ghostty one point four release, one reader asks: I still don't understand the point of Ghostty, Kitty, Wezterm... Konsole is way faster. To be fair, he adds that he really wants to understand what they bring. And under the JetBrains news, the complaint isn't about libghostty at all: They keep on messing about with the UI and adding AI stuff, meanwhile performance and resource usage aren't improving.

Verdict

So, libghostty isn't the engine of every agent tool. But it's quickly becoming the default engine for anything that shows a terminal: IDEs, editors and the new agent workspaces. If you're building tooling around agents, like a dashboard, a log viewer or a multiplexer, try libghostty-vt before you write your own ANSI parser. Just wait for one point oh before you promise anyone a stable API. Mitchell plans to tag it in the next few months.

What's next

The code from today is linked below. For a more complete single-file version, check out Ghostling, the official minimal libghostty terminal from the Ghostty team. It's about sixteen hundred lines of C, on Raylib. What should I build on libghostty next? Tell me in the comments. Tschüss, and bis bald.