blog.rust.gay

Libghostty 1.0 brings a stable ABI to terminal emulation

Mitchell Hashimoto announced libghostty-vt 1.0 on 6 November 2026. The library extracts terminal emulation from Ghostty into a portable C library with a stable application binary interface (ABI). For tool and editor authors, the 1.0 tag is less about a feature splash than a compatibility promise: releases now follow semantic versioning, and the C ABI is intended to remain stable across updates.

Terminal emulation is easy to underestimate because shells hide much of the complexity. The hard parts show up when full-screen programs, resize behavior, Unicode, mouse reporting, or modern keyboard protocols are involved. Hashimoto's post frames libghostty-vt as a way to avoid each project reimplementing that surface area, while giving packagers and embedders a library they can depend on without chasing internal churn.

What the 1.0 release promises

Hashimoto says 1.0 covers both the library and its C ABI. The design leans on ABI-friendly patterns: most objects are opaque handles, many reads and writes go through enum-keyed getters and setters, and selected structs carry size or reserved space so fields can be added later. On ELF platforms, exported symbols are versioned so a mismatched dynamic library fails by name rather than through a later crash.

The release process also adds compatibility checks. According to the announcement, continuous integration checks changes with libabigail against a committed baseline on Linux and uses golden type manifests on macOS and WebAssembly. That kind of enforcement matters because ABI stability is a social contract as much as a technical one; without tests, "stable" becomes a label rather than a guarantee.

Adoption beyond the Ghostty app

The strongest signal in the announcement is not the API design but the existing consumers. Hashimoto reports that more people now use terminals powered by libghostty than use Ghostty itself. The examples span editors, IDEs, build tools, and experiments:

  • JetBrains says its 2026.3 IDE terminal now runs on libghostty, replacing JediTerm for parsing and terminal state while the IDE keeps rendering and higher-level integrations. Hashimoto cites a JetBrains report of more than 12.5 million active users.
  • Neovim has an approved pull request to replace libvterm with libghostty-vt. The PR description notes that maintainers were waiting for a tagged release so distributions could package the dependency separately; the 1.0 release addresses that packaging requirement.
  • Hashimoto also points to KDE experiments, Vercel Turborepo's TUI output, devenv, fuzzing work by Antithesis, Emacs integration via Ghostel, a WebAssembly build called ghostty-web, and community bindings for languages including Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, and Java.

These are not all the same kind of adoption. A production IDE integration, an approved upstream PR, and a community experiment carry different weight. Still, together they show that the library is being evaluated as infrastructure, not just as a Ghostty implementation detail.

Packaging, licensing, and portability

The 1.0 release adds the artifacts distribution maintainers usually ask for: signed source tarballs, a companion dependencies tarball for offline builds, shared and static libraries, headers, pkg-config files, CMake package configuration, and SONAME handling on supported platforms. Hashimoto says the build honors --prefix, DESTDIR, and lib64, and that debug information is kept by default so distributions can split it.

On dependencies, Hashimoto describes libghostty-vt as MIT licensed with no copyleft code in the dependency tree. The announcement lists simdutf, Google Highway, a compact Unicode table for grapheme data, and Wuffs for Kitty graphics image decoding. Build flags can disable selected subsystems or substitute system libraries where appropriate.

Portability is broad in the published matrix. Hashimoto lists tested targets including Linux (glibc and musl), macOS, iOS, FreeBSD, Windows, Android, and WebAssembly, across architectures such as x86_64, aarch64, arm, and wasm32. The WebAssembly build is described as available in speed- and size-oriented variants, with optional subsystem removal for read-only viewers. Those claims are useful for embedders, but they should still be validated against the specific target and feature set an application needs.

Limits and what to verify

A stable terminal library does not remove every integration problem. Rendering, font handling, platform input, accessibility, and application-specific UI remain outside the core emulation layer. JetBrains' post makes that split explicit: libghostty handles parsing and terminal state, while the IDE handles rendering and higher-level features.

Embedders should also read the release as a starting point for their own testing. ABI stability reduces accidental breakage, but consumers still need to verify behavior for the escape sequences, protocols, and performance characteristics their users depend on. Neovim's PR, for example, shows both the opportunity and the cost: moving to a new emulator can fix long-standing issues, but it also requires careful migration work.

Conclusion

libghostty-vt 1.0 is a notable release because it turns a widely reused terminal core into a versioned, packageable dependency. The JetBrains rollout and the approved Neovim migration suggest real demand for a shared emulator with a stable interface. The next test is less about announcement momentum and more about whether downstream projects can adopt it predictably as the library evolves.

Sources


← back to posts