I went from the stock macOS Terminal, to Ghostty this year, to Supacode this week — and only then realized the last two run on the same engine. Here's the story of Ghostty, libghostty, and why a reusable terminal core matters.
For years I just used the stock macOS Terminal. It was there, it worked, and I genuinely never thought about it. But I'd been a fan of Mitchell Hashimoto's work long before Ghostty — I ran Vagrant back in the day and leaned on a handful of HashiCorp's tools over the years — so the moment I heard he was building a terminal, it was instantly on my radar. I actually tried Ghostty way back when it was still in beta — but it didn't click for me at the time (a skill issue on my end, honestly 😅). Then earlier this year I gave it a proper second chance and finally got why people were so loud about it. And just this week, after watching a video about it, I jumped again — this time to Supacode, for running multiple AI coding agents at once.
Here's the twist that made me want to write this: the tool I fell for and the tool I moved to are powered by the same underlying engine. That engine is libghostty — and it's quietly becoming more consequential than the terminal that spawned it.
What is Ghostty?
Ghostty is a fast, feature-rich, cross-platform terminal emulator created by Mitchell Hashimoto — co-founder of HashiCorp and the person behind tools like Vagrant, Terraform, and Vault. Ghostty itself was a passion project, built largely in his free time, with one stubborn goal: refuse the usual trade-off. Terminals have historically forced you to pick two of three — fast, feature-rich, or native UI. Ghostty set out to deliver all three at once.
Concretely, that means GPU-accelerated rendering, platform-native interfaces rather than a single cross-platform toolkit, and aggressive standards compliance. On macOS the GUI is written in Swift using AppKit and SwiftUI; on Linux it's written in Zig against the GTK4 C API. Both platforms share the same terminal core. Features include the Kitty graphics protocol, OSC 8 hyperlinks, light/dark mode notifications, native tabs and splits, theme switching, and a drop-down (quake-style) terminal on macOS. Coming back to it this year, it finally felt like a terminal that someone cared about — which, it turns out, is exactly the story.
A short history
Ghostty spent roughly two years in development — first as a side project alongside Hashimoto's full-time work, then as a primary focus after he stepped back from his day job. It ran a sizeable private beta: around 5,000 testers were selected from the 28,000+ people who had joined the project's Discord, a level of demand that's rare for a terminal emulator. (That beta was the one I bounced off of early — clearly the problem wasn't Ghostty.)
The public 1.0 release landed on December 26, 2024, open-sourced under the MIT license. It arrived to immediate, enthusiastic adoption — and almost as quickly, the conversation shifted from "nice terminal" to "wait, what's that core it's built on?"
What is libghostty?
From the start, Ghostty was architected to separate terminal emulation from the GUI. That cleanly factored core is libghostty: a cross-platform, C-ABI-compatible library written in Zig that both the macOS and Linux apps consume. In other words, the "terminal engine" was never tangled up with the windowing code — it was always a library waiting to be set free.
The motivation is bigger than Ghostty itself. Hundreds of programs implement terminal emulation ad hoc — code editors like VS Code, CI systems rendering build logs, countless embedded consoles. Because terminal emulation isn't their core business, those implementations tend to be incomplete, buggy, and slow. Hashimoto's argument is simple: ship one battle-tested, reusable engine and the entire ecosystem benefits. As he put it, libghostty has "the ability to make a far larger impact than Ghostty can as a standalone application itself." Knowing his track record of turning hard infrastructure problems into tools everyone ends up using, that line didn't read as hype to me.
libghostty-vt: phase one
The first piece being released as a standalone library is libghostty-vt — a zero-dependency C API for parsing terminal escape sequences and maintaining terminal state. It's so self-contained it doesn't even require libc. Because it's lifted directly from Ghostty's production code, it inherits the same hardened internals: SIMD-optimized parsing, full Unicode support, and protocol compatibility including the Kitty graphics protocol and tmux control mode. The core has been fuzzed and Valgrind-tested in the wild.
Initial targets are macOS and Linux (x86_64 and aarch64), with Windows, embedded systems, and WebAssembly on the roadmap. libghostty-vt is only the beginning — future libraries are planned for input handling, GPU rendering, GTK widgets, and Swift frameworks, building up toward a full embeddable terminal stack.
The ecosystem already forming (and where I landed)
Even before a stable tagged release, a surprising number of projects have started building on libghostty and libghostty-vt. The community now tracks them in "awesome-libghostty" lists. A sampling:
- Ghostling — the project's own minimum-viable terminal emulator, a single-file C program on the libghostty C API. The canonical reference for embedders.
- AI-agent terminals — tools like cmux and Supacode are native macOS terminals purpose-built for running multiple AI coding agents in parallel, with split panes, vertical tabs, and automation APIs. Supacode is where I ended up — one video was enough to sell me — and that's the part that made the whole libghostty idea click. I didn't move to a worse terminal to get the agent workflow I wanted; I got a purpose-built command center that still has a real terminal engine underneath, because it didn't have to reinvent one.
- Web embedding — ghostty-web brings the emulation to the browser, while restty pairs libghostty-vt with WebGPU/WebGL2, and vscode-bootty powers a VS Code terminal extension via WebAssembly.
- Mobile — SSH clients such as Geistty, clauntty, and vvterm bring Ghostty's engine to iOS and iPadOS with Metal rendering.
- Language bindings — Go (
go-libghostty), Elixir (ghostty_ex), Odin (ghosdin), Dart/Flutter, and Swift (GhosttyKit) are all in flight.
Why it matters
Ghostty earned its reputation as a genuinely excellent terminal. But libghostty is the more quietly consequential idea: a shared, correct, fast terminal engine that any application can embed instead of reinventing — badly — for the thousandth time. My own winding path from stock Terminal, to Ghostty, to Supacode is a tiny example of the upside. I kept changing apps to fit how I work, but I never had to give up the quality of the terminal underneath — because the engine travels with the ecosystem.
If libghostty succeeds, the win won't just be a faster terminal app. It'll be better terminal behavior everywhere a terminal shows up — from your editor's integrated panel to a log viewer in the cloud to whatever agent workspace you adopt next. A tagged release is expected within months of the announcement, dependent on readiness.
It's a familiar pattern in great infrastructure work: build the thing, then realize the reusable piece inside it is the real product. It's the same instinct that gave us Vagrant, Terraform, and Vault — so as a longtime fan who's now quietly running on top of Hashimoto's work every single day, I'm betting this one pays off too.
Sources: About Ghostty and Libghostty Is Coming — Mitchell Hashimoto.
