What is Libghostty 1.0?
On 6 November 2026, Mitchell Hashimoto announced libghostty-vt 1.0. The library is a portable C implementation of terminal emulation. Hashimoto extracted it from the core of Ghostty, the terminal application he started in 2022.
Hashimoto wrote that a year earlier the C API did not exist. At that point the Zig module had only just been merged, and Ghostty was the only consumer. Since then the library has become the engine inside products he describes as numbering in the hundreds.
Growth has been faster than the project expected. Hashimoto wrote that "more people today use a terminal powered by libghostty than use Ghostty the application, by a very large multiple." That claim rests on estimates, because the project does not track installations.
The headline is compatibility. Hashimoto wrote that the 1.0 release means "both the library itself and the C ABI are now stable." The project now follows semantic versioning, with a published policy on what each release may change.
The versioned artifact is libghostty-vt. It parses the bytes a program writes and tracks the resulting screen, cursor and scrollback state. It does not draw anything itself. Rendering, window management and input handling stay with the application that embeds it.
That division is visible in JetBrains' integration, where the IDE keeps its own renderer. Ghostty's documentation describes the macOS and Linux applications as consumers of a shared core called libghostty. The 1.0 milestone applies to the emulation layer, not to a finished terminal application.
The licence is MIT, and the library has its own release cycle, separate from Ghostty the app. Version 1.0.0 ships as a signed source tarball with a companion dependencies archive, so a distribution can build it offline.
Why does a stable ABI matter for a terminal library?
An application programming interface describes how source code calls a library. An application binary interface describes how compiled programs link to it at run time. A stable ABI lets a distribution update a shared library without rebuilding every program that uses it.
Hashimoto designed for that constraint from the start. Every object the library exposes is an opaque handle. Values pass through enum-keyed getters and setters, which lets the project add new fields without exporting new symbols.
Programs built against newer headers but linked to an older library receive a GHOSTTY_UNSUPPORTED result. They do not crash. The few non-opaque structs carry their size, so fields can be appended later, and enums are pinned to int across compilers.
The project enforces the promise in continuous integration. On Linux, every change is checked with libabigail against a committed baseline. macOS and WebAssembly builds are compared against golden type manifests, and exported ELF symbols are versioned.
Packaging work fills out the release. Tarballs install a shared library with a proper SONAME, a static library, headers, pkg-config files and a CMake package configuration. The build honours prefix, DESTDIR and lib64 conventions, and distribution notes ship with the source.
Why does this matter outside packaging circles? Security fixes and protocol support can reach users through a routine library update. Applications do not need a coordinated rebuild, and distributions do not need to carry private patches for each terminal.
Stability has a cost. Once an ABI is frozen, the design has fewer chances to change. The project handles this with reserved fields, unsupported results and careful versioning, but the constraint shapes every future addition.
Who is already using libghostty?
The largest named adopter so far is JetBrains. Starting with the 2026.3 release, the built-in terminal in its IDEs runs on libghostty. It replaces JediTerm, the emulator the company used for years.
JetBrains wrote that "libghostty takes over parsing and terminal state in our IDEs, while the IDE still handles rendering." The company said the new engine handles "almost 50 control sequences" that JediTerm ignored or misread.
The change fixes problems that matter to people running modern command-line tools. The Kitty keyboard protocol now distinguishes Enter, Shift+Enter and Ctrl+Enter, so multi-line prompts behave as documented. Terminal applications can also read the IDE's light or dark theme and follow changes.
The integration also answers standard terminal queries and exposes the extended colour palette. The old workaround that sent Escape and carriage return on Shift+Enter is no longer needed and is ignored.
Scale is the reason this release matters commercially. Hashimoto cites JetBrains figures of more than 12.5 million recurring active users across its IDEs. The JetBrains announcement does not repeat that number, so treat it as a figure relayed by the library's author.
Neovim is the next major candidate. An open pull request, number 39773, replaces libvterm with libghostty-vt inside the editor's embedded terminal. It has 30 commits and was approved in a GitHub review by gpanders in May 2026.
The pull request also closes a long-standing gap. It adds proper reflow of lines in the scrollback region, which resolves an issue opened ten years earlier. Hashimoto said maintainers had been waiting for a tagged release before merging, so distributions could package the dependency separately.
Hashimoto lists a wider set of consumers. KDE developers are experimenting with a Konsole replacement. Turborepo uses the library for its terminal interface, and devenv uses it to drive shells. Antithesis fuzzed text interfaces with it and found bugs in btop and other tools.
Smaller projects fill the rest of the list. Ghostel brings the library to Emacs, ghostty-web provides a WebAssembly build with an Xterm.js-compatible API, and OrbStack embeds it commercially. New terminal tools, including cmux and herdr, were built on it rather than writing their own parser.
Bindings exist for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart and Java. Hashimoto says a community list tracks well over a hundred projects. The documentation estimates that tens of millions of people use a libghostty-based terminal daily. That last figure is an estimate, because the project does not track installations.
How portable is libghostty-vt?
The library builds and runs tests on a wide matrix of platforms. That list covers Linux with glibc or musl on x86_64 and aarch64, plus macOS 13 and later. It also includes iOS 13 and later, FreeBSD, Windows on x86_64, Android and freestanding WebAssembly.
A second tier is built in CI but not tested. It includes bare-metal RISC-V and ARM targets, WebAssembly through WASI, Windows on arm64, illumos and 32-bit x86. Hashimoto says these platforms have known users, even though automated testing is not set up yet.
Binary size is modest. The WebAssembly build comes in two versions, one tuned for speed and one for size. The smaller one stays under a megabyte with every feature enabled. Compile-time flags can remove input encoding, search, selection and graphics for read-only viewers, roughly halving the module.
Dependencies are deliberately narrow. The library uses simdutf and Google Highway for SIMD, a compact Unicode table, and Wuffs for image decoding. Both SIMD libraries are built without libc++, and the dependency tree contains no copyleft code.
At run time the library needs only libc, and it can be built without libc for freestanding targets. Each dependency is recorded in a machine-readable manifest with its version, licence identifier and hash, which simplifies distribution packaging.
Windows packaging is more than a library file. The release includes a DLL with debug symbols, an import library and a static library. The project's CI checks that programs built with MSVC can link against it.
Resource use was a design goal. The library creates no threads and allocates only through an allocator the caller can customise. Hashimoto says he ran 10,000 active terminals with live shells on a four-core Linux server with 8GB of RAM. He used dash rather than bash, because bash used far more memory than the library and would not fit the budget.
Hashimoto also claims that a usable terminal now takes about 1,500 lines of C. That figure and the documentation's performance claims have not been independently reproduced. No outside benchmark of the 1.0 release was available at publication. Ghostty's own about page is more cautious, describing the project as aiming for the same class as the fastest terminals.
What can libghostty not do yet?
The most important limitation is scope. libghostty-vt is a state engine, not a terminal application. It does not open a pseudo-terminal, shape fonts, draw glyphs or manage windows. An embedder must supply all of that, which is why JetBrains keeps its own renderer.
Protocol coverage is also incomplete. Hashimoto says the project will focus on stability while implementing as many terminal protocols as exist. Each protocol has a switch to enable or disable it. That work is ongoing rather than finished.
JetBrains illustrates the gap between parsing and presentation. The JetBrains post says the library already parses OSC 52 clipboard access, desktop notifications, ConEmu progress bars, Kitty graphics and styled underlines. The IDE does not act on those sequences yet, so the features remain unavailable to users.
Availability is uneven. The Neovim pull request is approved but unmerged. JetBrains has shipped the change in early access builds that will carry through to the stable 2026.3 release. Until then, most users cannot choose the new engine directly.
The application itself still has a narrower reach than the library. Ghostty's download page lists macOS and Linux builds at version 1.4.0, with no Windows application. The library builds and tests on Windows, so the gap is in the graphical app rather than the core.
Maintenance capacity is another constraint. Ghostty's about page says "it's not a full-time job for any of us." A library used by millions of people, and now linked into commercial IDEs, depends on a small team and community bindings.
Finally, the usage numbers are estimates. Neither Hashimoto nor the documentation claims precise installation data. The 12.5 million figure comes from JetBrains' own reporting. The broader figure for daily users is explicitly described as a best estimate.
What happens next for terminal emulation?
Distribution packaging has started. Arch Linux users can already find libghostty-vt in the AUR, and the release tarballs were designed for official repositories. Wider packaging would make the library a normal system dependency rather than a bundled one.
Neovim is the next visible test. With the 1.0 tag now published, maintainers can merge the approved pull request and let distributions package the dependency separately. A merged Neovim port would put the library in front of a large audience of developers who never install Ghostty.
KDE's Konsole experiment is worth watching for a different reason. Konsole is a long-established terminal with its own feature set and user expectations. A successful port would show that the library can replace a mature emulator, not just power new projects.
The rise of agentic coding adds pressure. JetBrains explicitly cites tools such as Claude Code and Codex as programs that push terminals harder than a shell prompt. Those tools rely on modern keyboard and colour protocols, which is exactly the area where older emulators fall short.
Concentration brings both benefits and risks. A single parser means a security fix reaches every embedder at once, and protocol support improves everywhere. It also means a bug or design mistake can spread across many products, which raises the stakes for testing and governance.
Three things are worth watching over the next few months. The first is whether independent benchmarks confirm the performance claims. The second is whether Neovim merges and ships. The third is how quickly distributions adopt the library as a standard package.
Does a stable terminal library change everyday use?
For most people, nothing changes this week. The terminal they open is still the same application, and the library sits underneath it. The effects arrive through updates to the apps they already use.
JetBrains users on 2026.3 early access builds get the clearest early view. Multi-line prompts work with Shift+Enter, keyboard shortcuts reach the application intact, and the terminal follows the IDE theme. Rendering bugs involving borders, colours and leftover escape codes should also decrease.
Later updates should bring features that are already parsed but not yet displayed. Clipboard access from a remote server and desktop notifications when a long task finishes are not displayed yet. Progress bars and inline images also depend on the IDE side catching up.
Developers gain a different kind of benefit. Embedding a terminal no longer requires writing an emulator. The documentation provides a complete example that creates a terminal, writes bytes and reads the screen. Test harnesses for text interfaces become easier to build.
The wider significance is infrastructural. Terminals have quietly become the interface for coding agents, build tools and remote sessions, and their quirks are now everybody's problem. A shared, stable core reduces duplicated work and makes behaviour more consistent across products.
Whether that matters depends on how much software embeds a terminal. On current evidence, a lot does. The 1.0 release is less a product launch than a foundation others can build on.