libghostty 1.0 Explained

libghostty is a family of libraries that extracts the core terminal-emulation engine of the Ghostty terminal emulator so other applications can embed it. Its first library, libghostty-vt, reached 1.0 on November 6, 2026. What 1.0 promises is a stable C ABI and semantic-versioning compatibility, which means you can adopt it as the terminal foundation of your own app without worrying that a version bump will break your build.

The announcement came in Mitchell Hashimoto's post "libghostty 1.0", which took the number-one spot on the Hacker News front page on November 7, 2026 (1,045 points). This article relies on that post, the official site lib.ghostty.org, and Neovim's PR #39773 as primary sources, and covers what the library does, what 1.0 guarantees, how to start, and how it differs from alternatives (as of November 2026). Facts we could not confirm are listed in a note at the end.

- What it is: The terminal-emulation part of Ghostty, offered as a portable, high-performance C library. The 1.0 release covers libghostty-vt (VT refers to the escape sequences of text terminals)
- What 1.0 promises: Both the library and its C ABI are stable. It follows semver with strict ABI compatibility
- License and dependencies: MIT. The default build links libc; with SIMD disabled it can be freestanding

As covered in our Ghostty 1.4 explainer, Ghostty writes its core in Zig and builds its UI with each platform's native technology. libghostty is that core opened up for reuse. It has a release cycle separate from the Ghostty app and ships its own tarballs.

libghostty-vt takes the bytes a program writes to a terminal, interprets them, and keeps the terminal state (screen, cursor, scrollback) so you can read it back. According to the official site, the bytes can come from anywhere: a pty, a network connection, or a recording.

The last two rows deserve care. The official minimal example runs with no GUI and no real pty, so the library's scope is a state engine. The sources do not explicitly say who owns rendering and the pty, but the example makes clear that at least the caller does the wiring.

The official site lists these use cases: terminal emulators and multiplexers, web terminals and remote sessions, session recording and playback, test harnesses for TUI apps, and agents or automation that read what a TUI displays. For an AI agent to see a terminal screen, something must interpret escape sequences and reproduce the screen state, so the last use case fits current demand well.

On resources, the library creates no threads and allocates only through an allocator the embedder can customize. The author reports running 10,000 active terminals with live shells on a 4-core, 8 GB Linux server (using dash, because bash used too much RAM). The performance he talks about is parsing throughput and memory usage.

The point of 1.0 is not new features but a guarantee of stability. The announcement describes the design behind it.

In short, the promise that new features will not break existing callers is backed both by design (opaque handles and getters/setters) and by verification (ABI checks in CI). Because a C ABI can be called from nearly any language, a stable ABI also makes it easier for language bindings to keep up.

Packaging is also well prepared. Each release includes a signed source tarball and a dependencies tarball, so builds can run fully offline. Outputs include a shared library with a SONAME, a static library, headers, pkg-config files and a CMake package config, and the build honors --prefix, DESTDIR and lib64. Distribution packaging instructions are in PACKAGING-LIBGHOSTTY.md, shipped with the tarball.

The library is MIT licensed, and the announcement says no copyleft code is in the dependency tree. A machine-readable manifest lists each dependency's version, SPDX license and hash. The dependencies are simdutf and Google Highway for SIMD, a compact Unicode table for grapheme data, and Wuffs for decoding images in the Kitty graphics protocol. A build flag allows dynamically linking a system simdutf or Highway.

Platform coverage is broad. CI builds and tests Linux (glibc and musl, x86_64 and aarch64), macOS 13+ (x86_64 and aarch64), iOS 13+ (aarch64), FreeBSD (x86_64 and aarch64), Windows (x86_64), Android (aarch64, x86_64, arm) and WebAssembly (wasm32, freestanding). Bare metal (riscv32, thumb), WASI, Windows arm64, illumos and 32-bit x86 are built in CI without tests. Artifacts include an XCFramework for Apple platforms, a Windows DLL with import library, and Android builds with 16 KB page-size support.

Downloads are at lib.ghostty.org, and the repository is github.com/ghostty-org/ghostty, where the packaging guide lives. The announcement gives no explicit build commands, so we outline the flow only; see the Installing page in the official Doxygen documentation for details.

1. Download the signed source tarball and the dependencies tarball from lib.ghostty.org
2. Build following PACKAGING-LIBGHOSTTY.md (offline builds work because dependencies are bundled)
3. Reference the resulting shared or static library, the header (ghostty/vt.h), and the pkg-config or CMake files from your project
4. If you do not need SIMD, input encoding, search, selection or Kitty graphics, compile them out with build flags to shrink the binary

On bindings, the announcement says community bindings exist for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart and Java, among others, and that the awesome-libghostty list tracks over a hundred projects. Type safety and ownership semantics differ from calling the C ABI directly, so check how actively each binding is maintained before adopting it.

The most reliable minimal example is the C program on the official site (quoted from there; MIT). It creates an 80x24 terminal, writes bytes with bold green text, and reads the screen back as plain text. No pty and no GUI are involved.

It has three steps. First, ghostty_terminal_new creates a terminal (a NULL first argument selects the default allocator). Second, ghostty_terminal_vt_write receives the bytes a program would emit. Third, a Formatter (ghostty_formatter_terminal_new and ghostty_formatter_format_alloc) extracts the screen. Cleanup uses ghostty_free, ghostty_formatter_free and ghostty_terminal_free. The output is Hello, world!; per the example's comments, styles do not appear by default and can be enabled with options.

A real terminal emulator adds a loop that reads from a pty and draws the screen. The author's example of a minimal application, "Ghostling", is a terminal in about 1,500 lines of C, published at ghostty-org/ghostling, and is a good entry point for learning usage.

The announcement lists the following projects as using, or moving to, the library. The descriptions follow the post; check each project's current status yourself.

Neovim's PR #39773 ("replace libvterm with libghostty-vt") was marked ready for review on October 27, 2026. Per the PR, it ports focus reporting, bracketed paste, mouse and keyboard encoding, terminal query responses, text rendering and scrollback handling, and says scrollback now reflows properly on resize. It also bumps Zig to 0.17. A maintainer said it will merge after the Zig update and the upcoming 0.13 release, with a full nightly cycle before 0.14, and that the dependency must come from a tagged release rather than a commit. The 1.0 release meets that condition.

We have also covered Ghostty-based tools on this site: cmux for AI agents and the terminal multiplexer herdr are examples of where libghostty applies.

There are many existing terminal components. The table below compares their positioning. Items we could not confirm from this article's primary sources are marked "—".

Three differences stand out. First, libghostty-vt is a state engine, not a widget: you get freedom over rendering at the cost of drawing it yourself. Second, a C ABI makes it language-agnostic, and the build targets reach WebAssembly and bare metal. Third, it spells out ABI stability at 1.0. That does not mean the others are unstable; the cells are empty because our primary sources do not confirm it.

- People building a terminal emulator or multiplexer: delegate terminal-state handling and focus on rendering and UI
- People improving an IDE or editor terminal: the Neovim and JetBrains cases are good references
- People who want to test, record or replay TUIs: reproduce screen state from bytes without a pty
- People who want AI agents to read TUI screens: extract the interpreted screen state
- Safe to skip: people who just use a terminal. The Ghostty app is enough; see our Ghostty 1.4 explainer for app-side changes

Before adopting, check three things: whether you can supply rendering and a pty yourself; whether your target platform is in the tested CI set (bare metal and WASI are build-only); and whether the binding for your language is actively maintained.

Note: this article omits facts we could not confirm in primary sources, including which JetBrains IDE versions ship it, the quality of individual language bindings, other libraries' ABI stability or licenses, and the version mapping between the Ghostty app and libghostty.