Mitchell Hashimoto tagged libghostty-vt 1.0 on November 6, and the tag means the C ABI is frozen. The library is the terminal emulator core pulled out of Ghostty: parsing, screen state, scrollback, selection, search, the Kitty keyboard and graphics protocols, all behind a C API with no GUI attached. It is MIT licensed and needs nothing but libc at runtime. Hashimoto's announcement is the primary source, and he says he wrote it by hand without AI help, which given the length is a small flex.

The adoption happened before the version number did. JetBrains switched the terminal in IntelliJ, PyCharm, GoLand and the rest of the lineup to libghostty in the 2026.3 release, per the JetBrains platform blog in October. JetBrains reports 12.5 million active users. Hashimoto is careful to say that number is theirs, not a measurement of his library. He also says, in plain words, that more people now use a terminal built on libghostty than use the Ghostty app, by a large multiple. That is an odd place for a side project to end up a year after the Zig module first merged.

What 1.0 commits to

The ABI policy is the part of the release that will outlast the version number, because this is where most C libraries cheat. Every object in libghostty is an opaque handle. Values come in and out through getters and setters keyed by an enum, so adding a new config value or a new terminal mode does not add a new exported symbol. A program compiled against newer headers and linked to an older library gets a GHOSTTY_UNSUPPORTED return code instead of a crash. Structs that are not opaque carry their own size or reserved padding. Enums are pinned to int.

That is the design. The enforcement is better. CI runs libabigail against a committed Linux baseline on every change, and on macOS and WebAssembly it diffs against golden type manifests. On ELF platforms every exported symbol is versioned, so a mismatched library is refused at link time by name rather than discovered at 2 a.m. by a segfault. I have packaged and run enough C libraries to know how rare that discipline is. Most projects promise ABI stability in a README and find out they broke it when Debian files a bug.

Packaging got its own treatment. libghostty now has a release cycle separate from the Ghostty application, with smaller tarballs. Each release ships a signed source tarball plus a dependencies tarball laid out in Zig's cache format, so a distro builder can do a fully offline build. The build honors prefix, DESTDIR and lib64, emits shared and static libraries with SONAMEs, pkg-config files and a CMake package config, and keeps debug info on by default. The dependency tree (simdutf, Google Highway, a compact Unicode table, and Wuffs for image decoding) has no copyleft code in it, and there is a machine readable manifest listing each dependency's version, SPDX license and hash. There is a flag to link system simdutf or Highway instead of the vendored copies. That list reads like someone sat down with a Fedora packager and wrote down every complaint.

Where it runs

The CI matrix is the other half of the pitch. Fully tested, meaning unit tests and every example program, on these targets:

  • Linux (glibc and musl) on x86_64 and aarch64
  • macOS 13 and later on x86_64 and aarch64, iOS 13 and later on aarch64
  • FreeBSD on x86_64 and aarch64
  • Windows on x86_64, built with the GNU ABI and verified to link from MSVC through the import library
  • Android on aarch64, x86_64 and arm, with 16 KB page size support for Android 15
  • WebAssembly, wasm32 freestanding

Built but not tested: bare metal riscv32 and thumb, WASI, Windows arm64, illumos, and 32-bit x86. The WebAssembly build comes in a speed variant and a size variant. The small one is under 1 MB with every feature on, and compile flags can strip input encoding, search, selection and Kitty graphics to roughly halve it for a viewer that only displays output. Stripped functions stay exported and return GHOSTTY_UNSUPPORTED, so the ABI holds even when the function behind it does nothing.

The library creates no threads and allocates only through an allocator you can replace. Hashimoto's demonstration of that was 10,000 terminals with live shells on a Linux box with 4 cores and 8 GB of RAM. He had to use dash instead of bash because bash alone blew the memory budget. The terminal emulator was not the bottleneck. The shell was.

Who else is on it

Neovim has an approved pull request, #39773, replacing its libvterm fork with libghostty-vt. The maintainers held it until a tagged release existed so distributions could package the dependency on its own, and that condition was met on Thursday. The change closes an issue about reflowing scrollback on resize that has been open for ten years. In March, an analysis in the tracking issue concluded a direct swap was not feasible without regressions and that Neovim would need a new backend rather than a shim. The approved PR suggests they went and built the backend.

Beyond Neovim and JetBrains, the list is long. Vercel's Turborepo renders task output through it. devenv drives shells with it. Antithesis fuzzed TUI programs with it and found bugs in btop and others. A KDE developer is building a new frontend on it that will also work as a konsolepart replacement, though they said on Hacker News it is a new app, not a Konsole rewrite. OrbStack embeds it. Ghostel brings it to Emacs, and ghostty-web is a WASM build with an Xterm.js compatible API. Community bindings cover Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart and Java.

The one real complaint in the Hacker News threads was Zig. Debian and Fedora do not ship the Zig toolchain, so packaging libghostty means packaging a compiler first, and some people question how portable a project can be when its build language targets fewer architectures than GCC. Hashimoto's answer is the dependencies tarball and the offline build, which remove the network from the equation but not the compiler. For a distro maintainer that is still a real cost. For anyone building a product, it is a solved problem: download the tarball for your platform and link it.

Terminal emulation gets rewritten everywhere

Every product with a console reimplements a terminal. IDEs, editors, build tools, CI log viewers, browser based consoles, and now every coding agent that wants to show you what a command printed. Each one hits the same edge cases: wide characters, grapheme clusters, bracketed paste, the Kitty keyboard protocol, resize reflow. JetBrains' old JediTerm had its own set of these bugs, and the JetBrains post calls out that Shift+Enter now inserts a newline in Claude Code and Neovim because libghostty speaks the protocol those tools expect. That is a small thing that used to break for 12.5 million people.

A shared engine with a frozen ABI changes the economics. One team fixes the grapheme bug and twenty products pick it up on the next minor version with no recompile. Hashimoto's ghostling demo is a complete terminal in about 1,500 lines of C, and he claims it is faster and more capable than most terminals from 2025. I believe the first half without checking. The second half I will test when I have a weekend.

My prediction: within a year, libghostty is the terminal core in at least one of the big three browser based dev environments, and the Zig objection fades once Debian packages the toolchain to get Ghostty itself. If I am wrong, it will be because a competing library shows up with the same packaging discipline and a C build. Nobody has one today.