Quick Answer: Libghostty 1.0 is the first stable release of libghostty-vt, a portable C library for terminal emulation extracted from the Ghostty core. Released November 6, 2026, it commits to semantic versioning and strict ABI compatibility, so distributions can package it and apps can link against it dynamically without breaking on updates.
Libghostty 1.0 shipped on November 6, 2026, and the release matters less for its feature list than for its promises. As Mitchell Hashimoto wrote, the C API is now a complete terminal emulator, and both the library and its binary interface are stable. If you're building a terminal, embedding one in an IDE, or adding terminal output to a CLI tool, that changes the math. Here's what 1.0 actually guarantees, where it stops, and what I'd check before you depend on it.
Who Is Already Shipping on Libghostty
The most useful evidence is who has already switched. The terminal in JetBrains IDEs now runs on libghostty, and JetBrains reports over 12.5 million recurring active users across IntelliJ, PyCharm, GoLand, and the rest. Neovim has an approved pull request that replaces libvterm with libghostty-vt, and it closes a 10-year-old issue about reflowing scrollback on resize.
The list goes further. Vercel's Turborepo uses it to render task output in its TUI, devenv uses it to drive shells, and Antithesis used it to fuzz TUI programs and found real bugs in btop. Commercial products like OrbStack embed it, and newer tools such as herdr and cmux were built on it instead of a fresh emulator. The awesome-libghostty list tracks well over a hundred projects.
Here's the part most coverage skips. Mitchell estimates that more people now use a libghostty-powered terminal than use the Ghostty application itself, by a large multiple. That's a soft number, since most embedders don't report usage. Still, it shows the real value is in reuse, not in one terminal app.
Why ABI Stability Is Designed Around Not Exposing Structs
Most C library authors assume ABI safety comes from careful struct layout: append fields at the end, pad generously, and hope nobody reads the offsets. Libghostty takes the opposite route, and that's the counter-intuitive part. The library minimizes the surface where layout can break at all.
Every object is an opaque handle. The hundreds of values you might read or write go through a small set of enum-keyed getters and setters, so new values arrive without a new exported symbol. Programs compiled against newer headers and linked against an older libghostty get GHOSTTY_UNSUPPORTED back instead of a crash. The few non-opaque structs carry their own size, so fields can be appended later.
Enums are pinned to int on every compiler, as far as the C standard allows. That detail matters more than it looks, because enum width is one of the quiet ways a library breaks across toolchains.
The trade-off is real. Getter and setter APIs are more verbose than direct field access, and you'll write a little more glue code. In exchange, the library can grow without forcing every downstream project to recompile.
How CI Enforces the Promise
Writing down an ABI policy is easy. Keeping it true across releases is the hard part. This is where libghostty's 1.0 claim has teeth.
- Every change is checked with libabigail against a committed baseline on Linux.
- macOS and WebAssembly builds are checked against golden type manifests.
- On ELF platforms, every exported symbol is versioned.
- The dynamic loader refuses a mismatched library by name, so you get a clear failure at load time instead of undefined behavior later.
That last step is the one that saves you hours. A version mismatch that fails at startup with a clear error is far easier to debug than a crash three menus deep into your app. Here's where most library projects get it wrong: they version the API in documentation but never test the binary.
Packaging for Distributions
Packaging is where many C libraries stall, and 1.0 targets it directly. libghostty-vt now has its own release cycle, separate from the Ghostty application. It also ships its own tarballs with only the files and dependencies the library needs, which keeps sizes down and makes licensing review simpler.
Each release includes a signed source tarball and a companion dependencies tarball. The second one holds every Zig package in Zig's own cache layout, so a distribution can build the library completely offline. That's what distro maintainers actually need: reproducible builds with no network fetches during packaging.
The build installs shared and static libraries with a proper SONAME, headers, pkg-config files, and a CMake package config. It honors --prefix, DESTDIR, and lib64. Debug info stays on by default so distros can split it out. Everything is documented in PACKAGING-LIBGHOSTTY.md, which ships inside the tarball.
Platform Support and What's Only Built
Portability claims are cheap, so it helps to separate what's tested from what's merely compiled. The table below lists the platforms that CI builds and runs with full unit tests and all examples.
| Platform | Architectures | Artifacts You Get |
|---|---|---|
| Linux (glibc, musl) | x86_64, aarch64 | Shared library with SONAME and versioned symbols, static library, headers, pkg-config, CMake config |
| macOS 13+ and iOS 13+ | x86_64, aarch64 (iOS: aarch64) | dylib with @rpath install name, XCFramework for macOS, iOS, and iOS simulator |
| Windows | x86_64 | DLL with .pdb, import library, static library (GNU ABI; MSVC links via import library) |
| Android | aarch64, x86_64, arm | Shared library built against the NDK, with 16 KB page size support for Android 15+ |
| WebAssembly | wasm32 (freestanding) | Speed-optimized and size-optimized builds; the small one is under 1 MB with every feature enabled |
Several targets are built in CI but not tested, including bare metal riscv32 and thumb, WASI, Windows arm64, illumos, and 32-bit x86. The source says these have known users, but there's no automated test coverage yet. If your target is on that list, run your own tests before you commit.
Here's where it gets interesting for read-only use cases. Input encoding, search, selection, and Kitty graphics can be compiled out with a build flag, which roughly halves the WASM module. Every function stays exported and returns GHOSTTY_UNSUPPORTED, so your calling code doesn't change.
Dependencies, Licensing, and a Correction Worth Knowing
libghostty-vt is MIT licensed. The library compiles in a small set of permissively licensed dependencies: simdutf and Google Highway for SIMD, a compact Unicode table for grapheme data, and Wuffs for image decoding in the Kitty graphics protocol. Simdutf and Highway are built without libc++, so there's no C++ standard library dependency.
Every dependency appears in a machine-readable manifest with its version, SPDX license identifier, and hash. Distros can fill in bundled-library metadata straight from that file. If your distro prefers system copies, a build flag lets you dynamically link system simdutf or Highway instead.
The source also corrects an earlier claim. Mitchell once wrote that libghostty needed nothing beyond the C library and not even libc. The default build does link libc, because the SIMD paths use it and the default allocator is malloc. Turn off SIMD and the library becomes freestanding, which is how it runs on bare-metal RISC-V and ARM targets. Read the build docs before you assume a freestanding build.
Resource Footprint and What 1.0 Does Not Promise
Resource use is the other half of portability. The library creates no threads, allocates only through an allocator you can customize, and uses minimal compute and memory. Mitchell ran 10,000 active terminals, each with a live shell producing output, on a Linux server with 4 cores and 8 GB of RAM.
That benchmark needed a caveat he made explicit. He used dash, because bash used far more RAM than libghostty-vt and wouldn't fit the 8 GB budget. Your shell choice can dominate memory use, so measure with the shells your users actually run.
Most people stop here, but the limits matter more. The 1.0 label covers the ABI and the packaging. It doesn't mean every terminal protocol is implemented. The stated plan is to keep adding protocols, with options to enable or disable them at build time, so embedders can choose what they need.
Frequently Asked Questions
What is libghostty 1.0 and what does it change?
Libghostty 1.0 is the stable release of libghostty-vt, a portable C library for terminal emulation that was extracted from Ghostty. It changes the compatibility contract: the library follows semantic versioning, and the C ABI is protected by strict compatibility checks. Distributions can package it, and applications can link against it dynamically with confidence.
How do I link libghostty-vt into a C program?
Install the shared library, headers, and pkg-config file from the release tarball, or use the CMake package config. Then compile against the headers and link to the shared library. Because the library has a proper SONAME and versioned symbols, a mismatched library fails at load time with a clear error rather than misbehaving later.
Why does ABI stability matter for a terminal library?
ABI stability means a program built against one version keeps working with later versions without recompilation. For a terminal library embedded in IDEs, editors, and CLI tools, this lets downstream projects upgrade without rebuilding everything. Libghostty achieves it mostly by hiding struct layouts behind opaque handles and getter/setter functions.
Can you use libghostty-vt in a commercial product?
Yes. libghostty-vt is MIT licensed, and its dependencies are permissively licensed, with no copyleft code in the dependency tree. Each dependency is listed in a machine-readable manifest with its SPDX license, which makes compliance review faster. Check the manifest for your exact build, since you can swap in system copies of simdutf or Highway.
Libghostty 1.0 is the point where a terminal emulator became a dependency you can build on with confidence. Pull the release tarball this week, build it offline with the dependencies tarball, and note how long the build takes on your own hardware. Then pass this along to anyone wrestling with terminal embedding and libghostty 1.0 packaging on their platform.