libghostty 1.0 explained: the terminal engine inside JetBrains IDEs, now with a stable C API

A terminal looks simple: a window with text in it. Under the window there are two jobs. The first job is to understand what a program prints. Programs do not just print letters. They mix in escape codes, which are short hidden commands that say things like "move the cursor up two lines" or "print the next word in green". The second job is to draw the result on the screen.

The first job is the hard one. There are hundreds of escape codes from decades of different terminals, and every editor, IDE and web console that shows a terminal has had to write its own code for them, often with bugs. libghostty is Mitchell Hashimoto's answer: take the part of the Ghostty terminal app that does the first job, and ship it as a library anyone can use.

The library that reached 1.0 is called libghostty-vt (vt is short for virtual terminal). It is written in Zig, but it exposes a plain C interface, so almost any language can call it. The post lists community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart and Java.

Think of it as a state machine with a screen inside. Your app starts a shell or another program, reads the bytes it writes, and hands those bytes to the library. The library parses them and updates its picture of the screen: what character is in every cell, which colours and styles it has, where the cursor is and what has scrolled off the top. When your app wants to draw, it asks the library what the screen looks like now.

That split is why so many different products can share it. JetBrains draws the result inside a Java IDE. Turborepo uses it to show task output in its text interface. The WebAssembly build, ghostty-web, offers an API that matches Xterm.js, a terminal component that many web apps already use. Each one draws differently, but none of them has to get escape codes right on its own.

The library also handles the parts that are easy to get wrong: reflowing long lines when the window is resized, selection, search, and turning key presses into the bytes a program expects. On a build where you only need a read-only viewer, those extra parts can be switched off, which roughly halves the WebAssembly module.

If you build a tool that shows a terminal, such as an IDE, a coding agent, a CI log viewer, a web shell or a TUI test harness, you no longer need to write or maintain your own escape code parser. The library has no runtime dependency beyond libc, creates no threads of its own, and lets you pass your own memory allocator, so it fits inside servers, phones, browsers and bare-metal boards.

The new wave of agent tools is a good example. Coding agents run shell commands and need to read what those commands print, colours and progress bars included. The post names herdr and cmux as agent-oriented tools built on libghostty instead of writing yet another emulator.

For system designers, the release is also a clean lesson in how to ship a library other people depend on: keep objects opaque, add values without adding symbols, return a clear error for unknown calls, test the ABI on every change, and give packagers a tarball they can build offline. Those are the same ideas behind good REST and gRPC API versioning, one level lower.

Read next: Backward compatibility: new versions that old clients can still use