These are Ghostty GUI release notes, but I want to take a moment to highlight the libghostty progress we've made since Ghostty 1.3.
As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.
Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).
Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):
- Libghostty has nearly 100% coverage of all of Ghostty's core (and you can compile with flags to remove any of these features for size/safety): https://libghostty.tip.ghostty.org/
- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).
- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.
- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.
- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)
Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.
I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!
Because of your multiple "I am tired of saying this, but this text was written by me and not an LLM" in your blog posts, I want to tell you that I read it word for word. :D I know this comment adds not much but I felt it needed to be said.
One almost forgets how easy it is to read a wall of text when it was written by a human. This was nice to read (also because you can feel it's got care behind it).
At this point I just get frustrated reading AI prose. I tried for the past few months to just shut my mouth and force myself to read AI prose, since r/singularity wasted no breath telling people how they're Luddites for not marrying an AI.
I have been reading through pharma textbooks written before AI and realized it's so relieving to follow language that has been crafted over multiple editions by humans. When I started to realize how much easier it was for me to read textbooks than the average AI-assisted text, that's when I realized we are truly cooked (at least for this chapter of AI + writing).
Can you give an example of a pharma textbook that has gotten worse during the AI-slopp-ocalypse? Bonus Internet points for sharing any especially egregious passages!
They didn't claim they've read ai pharma textbooks, just used a pharma textbook (which I guess is heavy to read) as a comparison to being easier to read than ai written text.
Amen. I'll never, ever stop writing my own articles by hand.
I don't mind if my English isn't entirely idiomatic and all my sentence constuctions aren't "by the book" correct. I want to write, and I want anyone reading my writing to know that it's the product of thinking and editing that's unique to me.
As an aside, I once saw someone cite something somewhat profound and cited Rumi as the source, and I was like "hm that doesn't sound like him but maybe I'm just uncultured."
Turns out they were quoting Rumi from K Pop Demon Hunters and I indeed am uncultured.
I'm from the KDE project, and have been working on a new frontend built on libghostty-vt to hopefully one day ease our maintenance burden.
It's been a quite smooth experience, and I remain very excited about the lib. I believe you are successfully setting the standard. Big congrats for your 1.4.0!
It'll be a new app, but it does provide a drop-in replacement for konsolepart (along with also having a QML module API for embeds into Qt Quick-based app, closing a gap Konsole currently leaves open). I'm sure it'll be some time before it would be ready to replace Konsole as default, also because conversations like that take some time and are a community process.
Oh Konsole while great (efficient and feature-rich) is showing its age and has a bit of a widget bloat and an unwieldy configuration system. For that reason I switched to Kitty a couple of years ago when I was transitioning to neovim I'm have not looked back since.
This looks like a great opportunity for the KDE project to rethink its terminal application for the modern age. Text-based config would be amazing though not sure how it'll fit into KDE Frameworks etc.
Thank you for your work on this. When I was working on neovim core and started dealing more and more with the edge cases of libvterm and terminal emulation in general, I had the same thought "we should just have a gold standard library for this." But that was 6/7 years ago (2019) and a lot of stuff happened in that interim unrelated to engineering that demotivated me from pursuing it.
Periodically, I would run into TUI issues and think "I should just finally do it," especially around wanting to replace tmux in general. But I knew from experience the long tail of annoying issues for terminals that it's more time consuming than it appears, and so I again never bothered.
Thanks for the good work to raise all boats :)
I tend to move away from terminal emulation towards GUI when I can (and using custom remote protocols somewhat inspired by arcan), but TUI is still useful for a while. I actually had a need for a good terminal emulation library for the fallback TUI/pty attachment for non-gui programs for my supervisor, so I'll try out libghostty.
libghostty is brilliant and I'm very glad it exists. ghostel in Emacs is completely brilliant and so fast compared to anything else, a wonderful project fascinated by libghostty. another i might mention is zmx [ https://zmx.sh/ ] - process persister (detach, attach) with panes, tabs, hijacking the terminal. i always end up using tmux just for persistence and then am frustrated I can't remember how to copy etc. zmx has more features than some things of a similar nature and my understanding is that it's able to be taking advantage of libghostty things.
(a couple of us working on packaging libghostty and ghostty proper to for Guix at the moment )
Okay, that's fun:) ...so if I use this on an ESP* with a physical display and keyboard attached, at what point does it stop counting as a terminal emulator again?:)
> Libghostty now builds and is tested (in CI) for: [...] freestanding (i.e. direct on hardware with no OS).
I am really impressed. When I had read your original comment, I literally shouted oye! (meaning woah) because of how interesting it felt. Glad that I can see the demo as well.
But aside from the fun little demo, what are the real use cases that we can think of as well.
here are some that I have thought of
1. SSH'ing into a terminal (VPS) or being able to view what the AI agents are doing on that VPS and controlling them very thinly in your pocket.
2. I have a slight dream that I'd like to chip in but I always wanted to create something like monkeytype but on embedded-hardware. Something which can just plug to TV's and people can connect a keyboard and start to type.
3. Or another idea but being a book reader and having it connect to some library resource
(2) & (3) for the underdeveloped regions.
Maybe (1) can be good as well and could very well be a small computer terminal which can teach/help the underdeveloped regions.
I live in India and I see it first hand how genuinely just want to create some extremely minimalist software on extremely cheap hardware to make funding of them easier and more scalable.
This also makes the constraints work good as one of the govt's basically spent a lot of money providing mid/high end tablets to every children and it turned out to be quite catastrophic because although it was kiosked because it was just intended to watch videos or read resources.
Children paid people to crack it and then started using instagram on it. My mother is a govt. teacher and she strongly thinks that it was a waste of resources and even the parents of the children and local village meeting committees think so as well. I remember reading some local news articles about villages conducting meetings on how to prevent their children from such instagram addiction so quickly after the tabs were given.
I would like to hope that maybe someday someone creates the more optimal solution to the problems that I discussed and libghostty comes handy to the situation. Thanks for making it and have a nice day :-D
I hadn't thought about this angle -- inspiring as expected from Ghostty hacking!
Just took our TinyBubbles framework (TinyGo + BubbleTea) and added TinyGhostty [1]. We had all the parts in place.
The web demos use Booba [2] and our ghostty-web fork, so that's libghostty embedding another libghostty. The source cells are composited into our TinyHAL device abstraction. The UX is presented using "Booba Actions" which abuses OSC 7501.
This describes the differences between TinyGhostty and go-libghostty [3]. I've run other demos on embedded devices, but not this one yet. The fonts could use some love.
Just wanted to say thank you for all your contributions to our industry, Mitchell. I love Ghostty and your vision here, and evangelize it whenever I can.
I've tried to use terminal embedded in jetbrains' IDEs few years ago but they were full of childish errors.
Anyway I’ve learned my lesson, and now I only use terminals that aren’t integrated into an IDE.
Agreed on the value of libghostty. I switched from vterm to ghostel recently and it's solved some refresh issues I previously had with vterm when using CLI coding agents in emacs.
I prototyped this last week. Unfortunately the apprt abstraction I used isn’t something ghostty will externally support. So a proper console port needs to be rebuilt on libghostty.
I tried to use kmscon before, and it does work nice and is much faster. But, I can only have one app that is using DRM, i.e., I cannot start console/DRM image viewer from such terminal, or mpv, etc. That is a deal breaker and issue for me.
When reading the start if your comment describing libghostty, I was thinking: "Surely an example of a cross-platform software that could use such a thing is IntelliJ"
And right afterwards you write that not only it is the case, but the change is very recent !
Thank you for Ghostty! I've got an insane fork (AI generated) that uses variable width fonts and then does math so columns (like in top) still line up!
Any interest in moving console typography past the 80's, since computers are fast now?
Any plans for Ghostty to have the history of the terminal window reloaded on restart? Like the Mac native terminal app does? I am a heavy terminal user with a lot of tabs open, and after I restart the computer for whatever reason, I would like to have my terminal(s) as I left them.
The feature you're asking for is a terminal multiplexer. You want one built in, but to suggest terminal multiplexers are a workaround to requiring a terminal multiplexer is a stretch.
It is not a terminal multiplexer feature, it is one of the terminal software itself.
I do not know if you read my initial commment, but MacOS Terminal (native app) has this feature. And it is not a terminal multiplexer like tmux or what you proposed.
Why static output history for a session/tab with reload on restart should be a multiplexer feature?
I mean, the Ghostty GUI has already multiple tabs and split terminals, aren't those multiplexer features as well? I don't follow you.
Last time I checked it didn't work on Linux (or I couldn't make it work on my setup, I don't remember). It seems it still has some limitations but better than before.
Zig is also a C compiler
Here’s an example of Zig building some C code:
hello.c
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> printf("Hello world\n");
> return 0;
> }
$ zig build-exe hello.c -lc
$ ./hello
> Hello world
I misread the comment I was replying to, thinking it was about using Zig to port something, when it was actually about porting something that uses Zig.
You’re kidding right? That’s not what the support matrix on the Zig site shows. Plenty of CPU archs in Tier 3/4. No support for Alpha, HPPA, M68K, Sparc, or SuperH.
"portable" and "has ports" mean two different things. there might be targets Zig doesn't have great support for yet but what I meant is that bootstrapping a target to Zig is a simpler endeavor than it is for C
LLVM codegen is optional, and LLVM is being turned into a runtime dependency.
Zig has its own compiler backend. With limited arch support of course. Only used in debug modes for now.
I think the most interesting part is they rely on WASM for bootstrapping so all you need to make to bootstrap Zig anywhere is a WASM interpreter (if I understand correctly).
Yeah, the definition of "portable" being used is one that is not useful for most users, the fact that it's not in Fedora and neither Debian is a sign of it. Especially considering the demand for ghostty, it's a very cool project.
Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.
For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.
PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.
> has to pull in a whole programing language stack just for it
That’s implying a lot more than I think is the case for Zig.
Zig itself is a very lean and independent executable. It’s just one binary. Statically linked on Linux I believe. It’s even moving toward removing LLVM dependence.
I don’t know of any other language that aims to be as portable as Zig, including C itself. Of course, not all of those goals have been realised yet, but at this stage I don’t think there’s much preventing portability from Zig’s part itself, other than more architectures supported in its own compiler backend. And I suppose a 1.0 release would make it easier to get the compiler more widely distributed.
But can you actually paste into the terminal search popup now? :D Its the dealbreaker that keeps me on iTerm2 on my home machine, and the irritation that has me considering just launching iTerm2 and going back to it on my work machine. I still see the "Update Available: 1.4.0" message but knowing it was fixed would encourage me to close all my sessions and update.
If I don't want to use the wave of "venture backed ghostty wrappers" for remote mobile coding similar to Claude Code remote, what options do I have? Any plans for a first party remote solution that's not SSH?
If you like Paseo (I love it), keep an eye on Happier. I think they made the right choice by starting from a multi domain architecture rather than Paseo's independent domains shown on the same client approach.
terminal emulation keeps playing a central role in "computing" not withstanding it being an ugly prehistoric crocodile. Do you ever envision creating something modern, without the warts and with a design that incorporates half a century of lessons-learned? Something that fills this need but in a more elegant package? I'm asking because you're one of the few people that seems well-positioned to make a clean-slate replacement
I personally avoid using the terminal as much as possible b/c the whole things feels very archaic/fragile/baroque - but the central idea seems great and I'd love a modern take on it
the number of gotchas involved in bash scripting indicates to me it's very hard to make robust solutions using the terminal. Trying to understand how things like colors work in the terminal makes the whole thing look very duct-taped together
problem is not the terminal, it is the Unix philosophy for CLI programs. Non-structured text piping and bash scripting being major pain points for me personally.
There is no reason why programs input/output can't be schema'ed, consumed and piped in a type-safe manner. And why there can't be a better standard than bash for simple scripts.
But it is really hard to pull this kind of thing off unless you redesign most of the common tools by scratch and do so through a committee and somehow push it down people's throat through strict platform control.
You can rewrite all of the cli utils to fit your preferences. There’s no hard standard for piping (some utility pipe binary) and bash is not a requirement either (a shell is just a program).
No need to push it to people. Do it for yourself and create your community around it.
Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.
> Do you ever envision creating something modern, without the warts and with a design that incorporates half a century of lessons-learned?
Turns out that the warts are the incorporation of the lessons learned. For this reason, just before Wayland fulfills its destiny and becomes an immaculate replacement for X11, a new generation of developers will determine Wayland's codebase is too complex to comprehend and must be rewritten from scratch.
Although not necessarily advertised as such, I've been successfully using alacritty in several projects injecting terminals into things both serious and silly.
I wouldn’t say it’s better, because that’s very subjective, but it is more “feature complete”. Alacritty is very minimal and rejects community PRs for features often driven by their general ethos. libghostty supports a lot of features I don’t foresee making their way into Alacritty.
I use Alacritty and GNOME Terminal. I don’t have a great reason for not using or trying Ghostty other than I have a minor aversion to Zig. (Again, not a great reason and arguably a not good reason)
Right, this was my assumption. I think my question got misinterpreted in terms of tone (viz the downvotes). But I was nurturing a hope that Mitchell might come back and say yes then share some wisdom. :)
I'm super excited for you and this, but this is mostly a highlight list of who is using your library. I was kind of excited to read about the actual changes to the library but I suppose I can go read the changelog on my own.
As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.
Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).
Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):
- Libghostty has nearly 100% coverage of all of Ghostty's core (and you can compile with flags to remove any of these features for size/safety): https://libghostty.tip.ghostty.org/
- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).
- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.
- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.
- Libghostty powers all JetBrains IDE terminals, over 12.5 million active users. https://blog.jetbrains.com/platform/2026/10/jetbrains-termin...
- Libghostty is the most popular core behind the wave of venture-backed "agentic" terminals and editors, such as Herdr, cmux, and many others.
- Libghostty is being discussed and has been verbally accepted to replace the terminal core in Neovim: https://github.com/neovim/neovim/pull/39773 (work still to be done)
- Libghostty powers a really popular and powerful terminal emulator for emacs (Ghostel): https://github.com/dakra/ghostel
- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)
- And so much more: https://github.com/Uzaaft/awesome-libghostty
Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.
I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!