⏱️ Reading time: 9 min
Libghostty 1.0 now has a stable ABI, and JetBrains’ terminal, with 12.5 million active users, has been running on it since before it became official.
📑 En este artículo
- TL;DR
- What Is Libghostty 1.0
- What Happened
- Context and History
- Technical Details
- Impact and Analysis
- What’s Next
- Frequently Asked Questions
- What’s the difference between Ghostty and the libghostty-vt library?
- What does it mean for libghostty-vt to have a stable ABI?
- What projects already use Ghostty’s terminal library?
- Has Neovim already replaced libvterm with libghostty-vt?
- What languages have bindings for libghostty-vt?
- Is libghostty-vt free software?
- References
Mitchell Hashimoto, Ghostty’s creator, extracted the application’s emulation engine so that any program in C, Rust, or Python could reuse it without writing its own escape sequence parser. With version 1.0, that library (libghostty-vt) stops being an internal experiment and takes on formal binary compatibility commitments.
TL;DR
- Libghostty 1.0 arrived on November 6, 2026, with a stable C ABI and semantic versioning for Ghostty.
- JetBrains’ terminal (IntelliJ, PyCharm, GoLand) runs on libghostty-vt and reaches 12.5 million active users.
- Neovim approved a pull request to replace libvterm with libghostty-vt, closing an issue that had been open for 10 years.
- KDE is experimenting with a Konsole replacement, while Vercel, devenv, OrbStack, and Antithesis already use the library in production.
What Is Libghostty 1.0
Libghostty-vt is the portable C library for terminal emulation that Ghostty extracted from its own engine: it runs the escape sequence parser, the screen state, and the scrollback buffer so another program doesn’t have to write them, and Libghostty 1.0 is the version that stabilizes its ABI.
Unlike Ghostty, the terminal application Hashimoto launched in 2022, libghostty-vt has no interface of its own: it’s the engine other programs embed, similar to how SQLite is the database that hundreds of applications embed without the end user knowing it’s there.
What Happened
Ghostty’s terminal library doesn’t mark the start of mass adoption: it confirms it. JetBrains has already migrated the integrated terminal in IntelliJ, PyCharm, GoLand, and the rest of its IDEs to libghostty-vt, and according to the company’s own figures, that represents more than 12.5 million active users. Neovim has an approved pull request that replaces libvterm with libghostty-vt, also closing an issue that had been open for ten years about how to reflow the scrollback when the window is resized; the maintainers were waiting for exactly this tag so distributions could package the dependency separately.
- KDE: experimenting with a Konsole replacement built on the library.
- Vercel: uses libghostty-vt to render task output in Turborepo’s TUI.
- devenv: uses it to handle shells.
- Antithesis: used it to fuzz terminal programs and found real bugs in btop and others.
- Ghostel: brings it to Emacs.
- ghostty-web: is the WASM build with an Xterm.js-compatible API.
- OrbStack: embeds it as a commercial product.
On top of that list are code agents like herdr and cmux, built directly on the library instead of writing another emulator, plus community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, and Java. The awesome-libghostty list was already tracking more than a hundred projects as of November 6, 2026. According to Hashimoto, more people today use a terminal with libghostty-vt underneath than people who use Ghostty as an application, by a wide margin.
Context and History
Hashimoto started Ghostty in 2022, and since then the most repeated question about the project has been why build another terminal emulator instead of using an existing one. He answered that question himself in an earlier post titled “libghostty is coming,” but the underlying argument has shifted focus: there’s no longer a need to explain the intent, it’s enough to show the actual adoption.
A little over a year ago, in November 2025, the picture was different. The Zig module had just been merged into the main repository, the C API didn’t exist yet, and the only consumer of Ghostty’s C library was Ghostty itself.
Hashimoto used a JediTerm bug, the terminal emulator in JetBrains’ IDEs, as an example of how hard it is to write a correct VT100 parser. A year later, that same bug became obsolete: JetBrains replaced JediTerm with libghostty-vt, and the example that illustrated the problem turned into the biggest client of the solution.
Technical Details
What makes a C library stable isn’t new functions: it’s what can’t break when someone upgrades from version 1.0 to a later one without recompiling everything else.
flowchart TD
A["Ghostty (Zig)"] --> B["libghostty-vt (C ABI)"]
B --> C["JetBrains IDEs"]
B --> D["Neovim"]
B --> E["Bindings: Rust, Go, Python, Swift"]
subgraph Consumers
C
D
E
end
The design follows a classic pattern for long-lived C libraries, similar to SQLite or libcurl. Each object is an opaque handle: external code never sees the internal fields, only a pointer. The hundreds of values a program can read or write go through a small set of getters and setters indexed by enum, so adding a new value doesn’t require adding a new symbol to the library. A program compiled against newer headers but linked against an older version gets a GHOSTTY_UNSUPPORTED result instead of a crash or undefined behavior.
The few structures that aren’t opaque carry their own size in bytes, so fields can be added to them later, or they reserve padding for the same purpose. Enums are fixed to int on every compiler, as far as the C standard allows, to prevent a size change from breaking the memory layout across platforms.
How is it verified that the ABI didn’t break between two releases, instead of just trusting the maintainer’s word? The team runs libabigail on every change against a symbol baseline committed in the repository for Linux, and against reference type manifests for macOS and WebAssembly. On ELF platforms, additionally, every exported symbol is versioned, so the operating system’s dynamic loader refuses to load a library that doesn’t match by name, instead of failing cryptically later on.
| Aspect | Before Libghostty 1.0 | With Libghostty 1.0 |
|---|---|---|
| Binary compatibility | No guarantees: every build could break consumers | Stable ABI with semantic versioning and automatic CI checks |
| Packaging | No official tarballs or license manifests | Signed tarball plus a dependency tarball for offline builds |
| Consumers | Only Ghostty, the application | JetBrains, Neovim (pending), KDE, Vercel, OrbStack, and more than a hundred projects |
| Bindings for other languages | Nonexistent or informal | Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, and Java |
The release also brings the packaging infrastructure that was previously missing: every version publishes a signed source tarball along with a dependency tarball that includes every Zig package in the same cache layout the compiler itself uses, so a distribution can build the library without touching the network. The build installs the static and dynamic libraries with the correct SONAME, headers, pkg-config files, and a CMake config package, and it respects the --prefix, DESTDIR, and lib64 variables that distribution packagers use. The whole process is documented in the PACKAGING-LIBGHOSTTY.md file included in the tarball.
The license is MIT, and at runtime libghostty-vt needs nothing more than libc; it can even be compiled in freestanding mode for anyone who doesn’t want even that dependency. Its build dependencies include simdutf and Google’s Highway for SIMD routines, a compact Unicode data table for computing graphemes, and Wuffs for decoding images from Kitty’s graphics protocol. Both simdutf and Highway are compiled without libc++, so the library doesn’t carry a C++ standard library dependency either.
📌 Note: Libghostty-vt doesn’t depend on libc++, nor, in its freestanding variant, on the system’s libc: the entire runtime is contained within the library itself.
Impact and Analysis
The real impact isn’t technical: it’s economic. Before libghostty-vt, every application that needed to display a terminal (an IDE, a CI tool, an SSH client) had two options: write its own escape sequence parser from scratch, with all the bugs that implies, or adopt an old library like libvterm, which wasn’t designed for the pace of updates in modern terminals, like 24-bit color or Kitty’s graphics protocol. Ghostty’s library solves that dilemma by offering the engine of an application already proven in production, with a binary compatibility contract a packager can audit.
The tradeoff is that ABI stability is a promise of binary compatibility, not a guarantee of identical behavior: libabigail detects layout and symbol changes, but it can’t prove that a function’s semantics stay the same between versions. If a future version changes how it interprets an uncommon escape sequence, the ABI remains compatible and the program won’t crash, but it might render differently. For an IDE with 12.5 million users, that kind of silent regression weighs as much as a crash.
What’s Next
With the 1.0 tag now published, Neovim’s maintainers can move forward with the merge that replaces libvterm: they were waiting for exactly this release to package the dependency separately instead of vendoring it inside the repository. KDE’s Konsole replacement under testing remains experimental, with no release date. And the awesome-libghostty list will keep growing as more terminals, code agents, and TUI tools choose to embed the library instead of writing their own.
Try it yourself: clone the Ghostty repository and check the headers of libghostty-vt’s 1.0 release to see the stable ABI in real code.
Frequently Asked Questions
What’s the difference between Ghostty and the libghostty-vt library?
Ghostty is the terminal application a person uses to open a window and type commands. Libghostty-vt is the C library that Ghostty extracted from its own engine, designed for other programs to embed without showing any interface of its own.
What does it mean for libghostty-vt to have a stable ABI?
It means a program compiled against one version can keep working when linked against a newer version of the library, without recompiling, because the exported symbols and memory layout don’t change in incompatible ways.
What projects already use Ghostty’s terminal library?
The integrated terminal in JetBrains’ IDEs, Vercel’s Turborepo, devenv, Ghostel for Emacs, OrbStack, and code agents like herdr and cmux, among more than a hundred projects listed in awesome-libghostty.
Has Neovim already replaced libvterm with libghostty-vt?
Not yet merged: there’s an approved pull request, but the maintainers were waiting for the 1.0 tag to package the dependency separately before integrating it.
What languages have bindings for libghostty-vt?
The community maintains bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, and Java, in addition to the official C API.
Is libghostty-vt free software?
Yes, it’s licensed under MIT and at runtime only depends on libc; it can even be compiled in freestanding mode without that dependency.
References
- Mitchell Hashimoto, “Libghostty 1.0”: the original announcement of the library’s stable version.
- Ghostty repository on GitHub: source code for Ghostty and libghostty-vt.
- Neovim repository on GitHub: where the pull request that replaces libvterm with libghostty-vt lives.
- JetBrains: the company whose IDEs migrated their integrated terminal to libghostty-vt.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Foto de Fotis Fotopoulos en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments