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).
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.
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!
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'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
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.
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 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.
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.
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?
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
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
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)
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.
I've tried Ghostty and it's great, but Kitty's hints mode[1] is the one feature keeping me from switching from Kitty to Ghostty. There are quite a few discussions around this and similar features in the Ghosstty-org/ghostty Discussions[2] which I follow. Most of them are references from ghostty-org/ghostty/discussions/2394[3]. Maybe now that Ghostty has finished implementing Kitty graphics hints will be next .
Yeah this is what is keeping me from using ghostty. Unfortunately I think that discussion is dead and no one agrees on the design of the three or so separate parts. I maintain a fork with quick select for my own purposes but I can’t use it at work.
link = copy_to_clipboard=[0-9a-f]{7,40}
link = open=https?://[a-zA-Z0-9.]+[-a-zA-Z0-9()@:%_\\+.~#?&//=]*
keybind = ctrl+o>y=quick_select
Far from perfect. No way to bind to specific action:regex pair, so `ctrl+o` then `y` will show hints for both urls, which it'll try to open, and git hashes, which it'll copy to the clipboard.
Konsole is a fantastic and very mature terminal emulator, but it does have some real gaps that reveal its age.
The Qt toolkit that most KDE software is based on at some point introduced a next-gen toolkit-within-a-toolkit called Qt Quick, which most of our newer apps are written in. However, in its library form Konsole can only be embedded into apps that use the old gen toolkit. This is a real impediment to some efforts.
The old gen toolkit also typically doesn't use Vulkan or OpenGL for rendering (the new one supports both), and so Konsole's terminal renderer doesn't either. Konsole's real-world performance during use is arguably just fine, but it does leave a lot of performance and battery life on the table.
libghostty also has somewhat wider support for newer stuff like Kitty protocols, even though Konsole certainly trumps it in support for older stuff (like sixels).
There's some other shortcomings to Konsole that are not inherent to the technology, like accessibility support not quite being where it should be.
And while the default UI is, in most distros, OK, there sure is a lot of spiderwebs and spacebar heating lurking in the settings dialogs (of which there are strangely many). It's also a bit dated vs. our HIG at the moment.
Which is to say, these projects can and do have a point, especially if they provide a nice library instead of hoarding all the good to themselves.
A couple of annoyances I've had shipping CLI apps to Konsole users:
1. By default, Konsole disables OSC8 link support. Users can enable it manually, but you need to ship fallbacks by default since otherwise the default users will have a broken experience. Ghostty, Kitty, WezTerm, etc all ship working OSC8 support out of the box.
2. No built-in Nerd Font support, so if you want to render icons, you need to tell your users to set up a patched font or else have fallbacks. Ghostty and WezTerm ship built-in Nerd Font fallbacks if your configured font isn't patched.
That being said Konsole is much better than most emulators. iTerm2 is not bad, although it lacks Symbols for Legacy Computing Unicode support (which all of the above have, including Konsole, and which is very useful for drawing prettier terminal UIs). The worst by far is Apple Terminal, truly the IE6 of terminal emulators.
What's so bad about Apple Terminal? I've tried iTerm2 and others but never found a compelling reason to use them over the stock app. I don't live in the terminal like some do, though.
1. The Kitty keyboard protocol, which makes it impossible to distinguish e.g. Shift-Enter from Enter
2. OSC8 hyperlinks
3. It breaks on APC queries, so you need special handling to not emit them
4. Symbols for Legacy Computing Unicode support
5. The Kitty Terminal Graphics Protocol (or sixel)
6. OSC 9 notifications (or any of the later versions)
and a bunch of other stuff, this is just off the top of my head. For a long time they didn't even support 24-bit color, although they fixed that in Tahoe.
It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.
I believe that the default behavior should be to never open a link without a confirmation from the user that this may be done.
This should be enough to avoid malicious links. I do not believe that completely disabling links is a good default, because they are very frequently useful when you read some text file in the terminal window.
Yes, I agree. Ghostty et al don't open-on-click, but on hover they'll show you the URL and there's a keyboard shortcut + click to open. This is much better UX than disabling OSC8.
"One implementation of a feature had a bug, therefore this feature should be turned off on all implementations by default" is probably not going to convince people who think the feature is good.
If you don't want to be able to have clickable hyperlinks, by all means use Konsole — no one is forcing you to use Ghostty. But if you want to know why people like Ghostty's approach vs Konsole's, it's because Ghostty pushes terminal emulator features forward and is low latency. Konsole is low latency and adopts some but not all features that other people invent. It's a noticeable difference and so people who like the feature part of the former like Ghostty/WezTerm/Kitty more than Konsole. If you don't care or dislike that part, and want a more conservative terminal (that is also low latency), Konsole and many others further on the conservative spectrum exist.
It’s not just one implementation. Browsers have been struggling to get this right for decades and now we are destined to repeat all the same problems all over again with an entirely new syntax of inlined markup.
Bugs are fine, but this wasn't really a bug. It was lack of foresight.
I haven't used Konsole, but I do like this "recent" focus on terminals and have used many of the newer ones. Dailydrived st,alacritty,wezterm,ghostty,kitty,foot (probably forgot some) and I live for the regex pattern matching copy shortcuts etc.
I learned about OSC8 because my terminal (whichever it was) used one of its features and I didn't know it was possible to do that. My immediate thought was, how is the security?
And it is very disappointing to see how little effort people have spent on that. That is really one part that I expect more from modern incarnations of the old terminals where I can sort of forgive them for the lack of security posture.
I like ghostty, I really do. But this is not a good look, and to be clear it isn't just ghostty. Without looking for it I've stumbled upon several OSC8 and OSC52 bugs (in other software) recently.
I don’t. But the problem with OSC8 is it opens up whole new vectors for security vulnerabilities in an application that is, by intent, used for some of the most security sensitive work in our jobs.
I wouldn’t mind OSC8 so much if it had proper security auditing but it doesn’t. The whole thing was pushed by one guy on a GitHub gist who blocked anyone who dared discuss security issues.
At least with browsers, you have masses of people testing these things. But there’s no rigour to any of the tests that happen with terminal emulation. Let alone independent security audits.
And at this rate, it’ll only be a matter of time until we see “don’t cat untrusted READMEs” advice because they might contain boobytrapped escape codes. Which is an absurdly bad place to end up.
1) Personal preferences: different terminals come with different defaults, some people do not want to tinker with the settings, so they just stick with whatever immediately clicks.
2) Technical curiosity: some people probably started their own terminal project just for the fuck of having made their own - and they eventually gained a userbase.
3) Feature set: Most terminals implement most features these days, but at the time these projects started, you'd have a feature matrix between features and terminals because most terminals lacked some features; so people would pick whatever suited their needs.
Personally I've been using kitty for years mostly due to 3), at the time I chose my forever terminal, I evaluated like 12 different ones, and kitty was the only one that covered most of my needs without feeling like it suffers from random quirks, and I like that it has built-in terminal multiplexer (a'la tmux) and emoji picker.
The terminal ecosystem needs to change, and these terminals support a lot of cool features. Ghostty's pure reusable terminal state machine being a source of truth, Kitty graphics, Wezterm and its mux domains & lua config, lots of cool ideas there.
Having having an industry player like hashimoto's superlogical driving terminal features is the extreme version of that
> Ghostty's pure reusable terminal state machine being a source of truth
Can you please explain what this means? I have Ghostty installed just as a backup to use when I have terminal saturation in my default (MacOS Terminal). But other than being super responsive, I don’t know why people love it so. Perhaps I’m missing something large and compelling.
I assume the quote is referring to libghostty. In which case a lot of different tools like vs code, Emacs, Gvim, Intellij and other IDEs, even web consoles on stuff like Azure essentially use and reimplement the same core, the idea behind libghostty is to replace those with a common component where long term development can better support the needs of all terminals.
In terms of ghostty itself its just a highly competent use of libghostty, Mitchell’s message above about it being a tech demo is tongue and cheek, but its not far off from the truth. It is just a really solid no bells and whistles, bar excellent execution, terminal emulator that uses libghostty.
Terminal state machine parsing is a very tricky thing, especially when you have people defining arbitrary protocols to interact with it. So having one implementation simplifies the development a lot. Of course this buys you into their ecosystem and whatever ghostty specifically supports etc.
A lot of other terminal emulators can expose similar reusable things (alacritty comes to mind) but libghostty is the most well supported one
It being super responsive is the reason I switched to it. MacOS terminal had issues keeping up with Claude Code. It would frequently be super slow rendering the text output or sometimes just stop altogether.
When looking at options I looked at speed and simplicity. Ghostty fit the bill but I did evaluate iterm as well. Excellent terminal but too many features for what I was looking for. I live in the terminal but am not a Terminal App power user if that makes sense.
So, it really comes down to what you want and what your workflow looks like. Ghostty has been flawless for me the past 9months. It gets out of the way and just works really well.
The issue the OP mentions was likely a known memory-leak in Ghostty that has since been fixed. Claude was triggering the bug in Ghostty but the bug was in Ghostty. Ghostty's author blogged about it
I might not be using the correct terms. But, here is what I was seeing:
- in a running session text display would slow down intermittently. Like 2-3 words a second
- occasionally terminal would stop, some times in the middle of showing a response, and would need to restart the terminal to get it back. But I tailed the session logs and Claude code didn’t think anything was amiss. It was proceeding like normal
After switching to Ghostty these issues went away and has been rock solid since then.
Why would a terminal multiplexer need an entire company behind it? Especially since it looks identical to the many other vibe coded alternatives (including my own lol).
What is your justification for this statement? Why does it need to change, and what does it need to change to? Personally, I've not felt this (and I spend a lot of time in the terminal). Fish shell and Byobu give me everything I've ever wanted.
Like the poster you were replying to, I don't understand what these new terminal emulators bring to the table, other than potentially more resource usage.
I feel that there's something here that I'm missing (ghostty is clearly popular, so it must bring something both new and useful to the table), but I'm genuinely not sure what that is.
I assume that this depends on your computer/GPU/GPU driver.
I have used Konsole for many years and I have used kitty for about 2 years in 2024/2025, then I have switched to ghostty around the beginning of 2026.
At least in my computers (with NVIDIA GPUs and Gentoo Linux), kitty was many times faster than Konsole and Ghostty even faster.
Moreover, in the now somewhat distant past when I was still using Konsole, it did not have some font rendering features that I desired, but that might have been solved meanwhile.
A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window, which happened frequently with all terminal emulators older than kitty and ghostty (I have always used CPUs with enough cores so that compilation itself is very fast, so the older terminal emulators become the bottleneck).
Yeah, I recently tried out Kitty and Ghostty just feels much smoother when rendering most TUIs and even some more basic stuff like the homebrew progress bar. It is also better about respecting platform conventions for things like keybinds and window/tab behavior.
I have been using Alacritty for its GPU acceleration long ago. Ghostty was slightly faster, but then Ptyxis was also faster. Since I preferred to configure my terminal with GUI, I have switched to Ptyxis.
For me: it doesn't really "bring" anything more than what I expect from a terminal.
In Mac, we had the default terminal app which has some problems with TUI apps and other small issues. iTerm2 is the replacement that most users use, but it become too bloated with useless features and AI, while it was hard to keep a good config file that I could share between devices. Ghostty was a sane mid-term for me: a good and modern terminal, with a simple config file, maintained by someone that I trust (Mitchell Hashimoto) and only that.
About Linux: I don't use Ghostty in Linux because I'm comfortable with Konsole.
There's always gonna be something that's better, faster, bigger, badder, stronger, thicker, firmer, etc., and terminals really aren't one of those things where I am interested in exhaustively testing all of them to find the truly greatest one. A terminal is also one of those things where if you find one that is perfectly adequate then there's little motivation to even bother using trying one. And there's the whole "devil you know" aspect. The only reason I rarely try a different terminal is if the stock terminal on whatever OS I'm using lacks some basic niceties that should be expected in the year 2026.
I like Ghostty because I find it both fast and configurable, and it's multi-platform without treating macOS like the red headed step child. I also appreciate how its configuration is text-based, which I prefer to someone's opinion of how a configuration GUI should behave, and I think it's good the developers aren't wasting a second of their time thinking about a configuration GUI.
I also thought like that, but you only to set some defaults and you're ready to go. If you still prefer a GUI there are online generators. Nowdays you can also vibecode them, they are very simple and any LLM will do it right
If you have to see them, they aren’t defaults. It’s bad enough that Windows Terminal doesn’t expose its full configuration and forces you to edit the config by hand for more advanced stuff. Feels like a step backwards when something like iTerm 2 gives you access to all settings in a (admittedly kinda crappy) GUI. This also kinda begs the question why there’s not a /TUI/ configuration manager shipped…
There are mature emulators for decades now, why go backwards? I guess there are a few tiny features that might be useful, and am open to them. But a new project needs to be strictly better, not two steps forward, one step back.
Ghostty is getting there though, and today is a milestone, not complaining too loudly.
The lack of a config GUI in ghostty used to bother me, but to be honest now I just describe to Claude what I want to change and it does it. It would still be nice to have one eventually but I can see the argument for deprioritizing it.
I tried a bunch of terminals and ended up switching back to xfce-terminal, fastest I have tried by far. (It's just the default that ships with my distro.)
Actually I think xterm was even more performant, but the eye sore wasn't worth it for me.
I don't think Konsole is actually faster than Kitty or Alacritty. Kitty is really nice and an innovator in a lot of terminal standards. It's also non-commercial and not related to any sort of startup (not that Konsole is either). It's definitely my first choice of the bunch, followed by Alacritty.
Konsole seems to keep up with modern features as well. For instance I realized yesterday that it renders the newer progress codes that clis can emit. I am content.
For me it's simply that iTerm2 got really fat over the years, and Ghostty was a nice and slim alternative - plus it has one of the better Kitty Graphics Protocol implementations which is fun to tinker with. e.g.: https://github.com/floooh/chipz-kitty (needs zig-0.17.0).
For me, the main reason to use Ghostty is simply that mouse support works right out of the box. In Konsole clicking a spot to move the cursor only works if you're using Bash. While it also works with the Fish Shell on Ghostty.
Same here. ghostty + fish = just works out of the box, no plugins or dotfiles needed. Plays well with accessing remote tmux claude/codex sessions as well.
To add to the other good points made in sibling comments, MacOS has butchered fullscreen to the point where some of us depend on MacOS terminal emulators having the "non-native fullscreen" config option. Personally, Ghostty does the best job supporting my preferred terminal environment of non-native fullscreen with tabs that works with an auto-hiding menubar and the camera notch.
Yeah. It's slow on Linux, for sure. I use Foot, which as far as I've tested is the fastest to launch. I use Niri and launch Foot terminals all the time as part of my workflow (it's just how my mind works), so time to launch matters to me.
You could, but my answer would probably skew your opinion about as much as yours did mine. :D
To me the point of Konsole is that it works well, plus it's already there. Ghostty I need to make an effort to have it, however small it is, and I'm just trying to understand what I'd be missing if I didn't.
Konsole is not already there for me. I would have to make an effort to get Konsole, just like Ghostty. I’m struggling to see what point you are trying to make. Do you want someone to tell you Ghostty is better than Konsole to convince you to switch, or … not?
This days I don't really care about the terminal I use. It's xterm on OpenBSD, konsole on Fedora KDE, terminal.app on MacOS,... As long as I can use cli and the few TUI software I use.
Kitty is really nice, a programmable terminal that does everything I want, GPU rendering, etc. Haven't used Ghostty yet but one of its advantages is libghostty, modern terminal emulation as a library.
> libghostty: a cross-platform, minimal dependency library that exposes a C API so feature-rich, correct, and fast terminal functionality can be embedded by any application anywhere.
Oh the author actually posted about it just now in rich detail. It's pretty exciting for people who spend much of their time in the terminal.
>I still don't understand the point of Ghostty, Kitty, Wezterm...
WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.
That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.
for terminals I personally am using kitty, but libghostty is great and powers ghostel in emacs which is amazing. Also note if you start trying to look at unicode correctness, in my experience ghostty is in general the best among all alternatives.
> Konsole is way faster than any of those on my computer and it has all the usual suspects I'd expect from a modern terminal emulator.
Same boat here, though I also get to enjoy some of the benefits of libghostty, via ghostel in Emacs. Ghostel is noticeably faster when there's a lot of output being dumped, but I don't often need the speed and use it only because it's integrated rather well into the rest of my Emacs.
> tmux -CC integration
If you can stomach Emacs, there are at least two packages that implement this, one via eat and another via vterm, though none via ghostel just yet. Shouldn't be difficult to port, though.
I don't know about the others as I used Terminal.app on mac since Panther, but Ghostty has been a pretty good upgrade, at first offering 24-bit colour which Terminal.app didn't have at the time of its release. I also like the shell integration such as easy selection of command output. I don't ask much from a terminal as evidenced by using Terminal.app for almost 2 decades, but Ghostty has not once been an issue and is 'invisible' to me.
The advertised point is it needs zero config to work outside of the box. For example nerd fonts are included by default whereas you need to install them if you are using let’s say iterm2.
I'm not sure why you want shaders, but if you use a coding agent in the terminal you definitely want image support. Otherwise it's very hard to see what the agent is seeing.
I can use Ghostty and use the same featureful terminal on Linux and macOS.
I also hate configuring Konsole, most KDE apps for that matter. Being able to have a plaintext configuration file I can keep in my dotfiles is way simpler.
I don't know Konsole, but kitty have tons of features other "plain" terminals lack. It's not just about speed (which I never got the obsession about either)
I'd love to, I switched back to iTerm after not really feeling any big difference in my uses cases, but also hating the crappy plain text with no defaults listed config that required me to use a goddamn web app to comfortably learn and fill out.
There was also some pretty noticeable differences in character rendering between the two with identical-as-I-could-make-them font settings.
> here was also some pretty noticeable differences in character rendering between the two with identical-as-I-could-make-them font settings.
I'm pretty sure it was iTerm's problem.
I've tested a number of Terminal Emulators on macOS and Ghostty's rendering is always superior.
Yeah, except the default config file doesn't EXIST and there is nothing but the reference docs to tell you what the hell you're supposed to put in there. What am I supposed to do, guess? Is it `font=` or `font-family` or `font-name`? That's fucking terrible. The very existence of a website like this: https://ghostty.zerebos.com proves the failure in my opinion.
Good tools should be invisible. Good tools behave the way I want them to. That's different than the way you want them to behave. Or appear. Good defaults are good. That is absolutely no excuse to abandon good UX for configurability.
I'm happy the defaults work for you. They don't for me.
And don't get me wrong, ghostty is a fine terminal and I don't begrudge it, and I think libghostty is awesome, it's just not the application for me.
What do you mean “there is nothing but the reference docs to tell you what” valid configuration options are? Where would you expect that to be documented otherwise?
I would expect the default configuration (which does set keys to specific default values) to appear in my ghostty config file. If there isn't a UI, how the fuck am I supposed to know what the names of all of the keys are? How am I supposed to know what is even possible to change?
A brand new ghostty config is an empty file because it only shows you what the overrides to the default config are, which means if you want to change your ANSI colors, off to the docs to look up what they're called as config keys and what format it expects as a value. Want to hide the Secure Keyboard Entry overlay? Off to the docs to figure out what the key is called. Is it a boolean? Does it accept true/false, or only 0/1? Who knows! Go to some website and scroll and scroll and scroll and maybe you can find it.
Or they can just put 'macos-secure-input-indication="true"' in a file it creates when it launches for the first time and notices it doesn't have a config file in an expected location. It can put that in there and every other default setting it actually is setting for itself, instead of just keeping it all socked away in the compiled executable as a behavior. Show me, on the computer I have, in the file I'm supposed to edit anyways, what all of the possible keys are, and some general indication or hint of what the fuck I can put in there. Don't make me fetch it for every single goddamn boolean. I wouldn't need to open a fucking web browser to hide the secure input icon because I'm not stupid and could infer it from the default config. Oh I bet it's the 'macos-secure-input-indication' key I need to set, lets flip that to false. There's a limit to this of course, not everything is going to be immediately clear, and for keybinds it might be a little preposterous to have all of the defaults listed, but for setting my themes? Colors? Fonts? Basic shit? Don't make me work, I have better things to do, but I need to be able to read my terminal.
The lie of "zero config" tools is that they are absolutely NOT zero config. They are usually full of changable behavior and they just skip the part where they make it easy for you to figure out how to change any of it, because...I dunno...configuring your software to work the way you want is...bad? Sounds stupid to me.
I was sceptical for decades as well.
But they are amazing - no more closing the xterm by mistake. I'm using those because I wanted for example a single window with THREE consoles open at once AND being able to handle some ANSI crazy theming.
Lots of things bother me about my terminal emulators, and it's almost always in the category of "things don't work right". It's never "I wish my terminal emulator ran faster." Ghostty seems hyper focused on speed, with the negative side effect that compatibility breaks - in practice. I get that it's following all the newest standards or whatever it's doing, but in reality it always needs custom setup to work right. And for me the net effect is that it's always creating problems, not solving them.
Why should I use Ghostty over iTerm2? I don't care about fancy fonts, iTerm2 speed (for me) is plenty (just tested against 1.4 -- don't see noticeable difference on MBP M1) and I do like to tweak some options/settings (and was just mildly annoyed when hitting `cmd+,` opened my default text editor...
The docs for ghostty's config file is a lot easier to reason about for one. The built in themes are IMO a lot better in ghostty.
Nowadays, it's also a more fun community. I end up learning things about terminal rendering I never would've otherwise just by reading ghostty-related blogs.
If you’re fine using iTerm just use iTerm. In my case I used iTerm for years and kinda liked it, but not completely. I’d been looking for an alternative for years but couldn’t find one I like (Alacritty doesn’t support pane splitting, Wezterm has full code config which I hate, Kitty doesn’t look good on Mac, Terminal.app is dog slow…). Ghostty just fits my needs pretty much exactly.
I am an iTerm2 user but I find its .plist config file a lot anachronistic and, if I may say so, quite absurd. I have tried too many settings and I still struggle with keyboard inputs getting trapped wrongly, lost, et cetera, the warnings that appear out of nowhere and I notice was wrong. But iTerm2 is the only terminal app that looks the best on mac (even better than the Terimnal.app itself) and somehow sits naturally with everything else around. I am sure for a lot of terminal users it might not even the last concern but for me it is. I tried Ghostty but I just couldn't like it. Kitty won't even be a consideration for many reasons (one is better off not discussed here). cmux is indeed quite good but it has become a HYDRA and will keeps on growing in every direction. iTerm2 would do great to keep the outer clothes and possibly adopts the base of something else. It isn't particularly snappy either. I moved back from Ghostty to iTerm2 even though I felt usage wise Ghostty was suprior. Ghostty just felt out of place.
I'm also very reluctant to switch and will not switch anytime soon. I have small compact tabs which I color code dynamically with iTerm2 and also custom profiles with custom keyboard keys overrides by program and directory. So the "harness" around the terminal is more feature rich with iTerm2.
These kind of features are not available in Ghostty in this form.
And about backups in iTerm2: Just do an export and maybe also a backup of your profiles. So that works.
I also do not care about a "super fast" terminal... my iTerm2 is fast enough for 99% of use cases for me.
I have a feeling you already know this. You can direct its unnecessarily monstrous .plist file to a folder of your choice and that way it will remain synced and/or backed up all the time if that folder is. [General > Settings > External settings]
There is no reason. I switched from iTerm 2 and while Ghostty is a lot faster and lighter, it has occasional rendering issues and does not detect URLs as well. It also doesn't have tmux control mode which I really liked.
I quit using iTerm 2 because of the AI features. Ew.
I don't think anyone is trying to convince you you should use Ghostty over iTerm2. It's a technically excellent terminal built with an incredibly rigorous and well thought out guiding philosophy and a remarkable amount of passion. Nobody cares if you want to run it or not.
I find iTerm2's constant prompts to update to be annoying. It has also crashed on me a few times. Lastly, I also prefer ghostty's text-based configuration.
For me even just the config format is such an upgrade that it was worth switching. Just a simple text file I can backup anywhere and actually read without clicking in a tabbed GUI where I never seem to remember what goes where. iTerm2 still has that weird thing you have to export right?
It’s subjective. The config format is a downgrade for me. The only settings I change is the color theme anyways. The terminal default should work well. It takes four seconds to use the mouse to open the theme config and pick a theme. It takes at least five minute to find the config file location, the syntax for the config file, understand whether it uses fs events to auto reload, and then decide to include or exclude it in your backups. I don’t intensely customize my terminal emulator so it’s not worthwhile. On the other hand my Emacs config is more than 500 lines long and that’s worthwhile.
I think you hit upon what bugs me about file config. It's not the file, it is having to find it, find the docs, find the syntax, find the keys, find the values, etc.
If it was always in a standard format, it wouldn't be a problem. Something like dconf, without the poor design.
Ghostty is so great. I am very thankful to Mitchell for dedicating so much of his time to making a terminal that is truly great. Finally, somebody really cares and has the technical abilities to materialize that care as great software.
Also, ghostel in Emacs is fantastic as well (of course in a big part thanks to libghostty) — most of my work has now shifted into Emacs as a result.
This depends on the individuals' character -- when I look around, I mostly see people who become jerks/a-holes once they get money. Especially in the tech world. Look at what Google founders do with their money (evading taxes, mostly), or at others who became outright nazis and support far-right movements across the world. In the best case scenario they just keep buying yachts and villas and stay relatively quiet.
Mitchell is a beautiful exception and it makes me happy.
i tried ghostty, rio, wezterm, they all stuck for about a month or so... then the subtle usability issues become too much, and i wonder why i switched from iterm2 to begin with. there's something to be said for years of polish, and feature work that is well-baked.
iterm2 is fast, reliable, and second nature. i don't have to edit settings every day.
btw I used iterm2 for years as well and sometimes tried others.
I now use ghostty it’s faster definitely. Yes it has some quirks which is hard to overcome as a iterm2 user. But I could live with it. I think ghostty is basically also the only alternative to iterm2
While I'm not a hard core terminal emulator expert or tweaker, it was a bit of a learning curve to get into Ghostty after iTerm2. I hope this latest release makes it easier to edit the splits, haven't tested yet.
But the biggest thing that made me stay on Ghostty was that there's a freaking config file. With iTerm you had to export the profile and keybindings, and then import them on a new system which was clumsy, and easy to forget. Now ghostty.config is just one of my dotfiles, with a clear understandable git history, I love it.
Yup I switched to WezTerm from iTerm2 and being able to version control the settings is one of the biggest benefits (especially because WezTerm allows more complicated Lua scripts)
I used iTerm and iTerm 2 for almost 20 years before switching to Ghostty full time in 2024 with minimal fuss besides the muscle memory of "cmd+space ite" switching to "cmd+space gho" to launch it!
Do you have specific examples of usability issues?
My main issues with ghostty: the global shortcut for quick window suddenly stops working and works again only if I focus ghostty. (On a mac)
The other one is quick window goes out of the monitor if i have disconnected and connected the laptop from minitor.
Another: sometimes autocomplete suggestions are shown incorrectly in some weird location (like middle of the screen, not at the cursor), again occasionally.
The only other cause I've encountered is if a secure input (password) field is focused, since macOS won't give apps global keyboard events for obvious reasons. If you focus a normal text input, it should start working again.
I'm happy with ghostty now too, but until a couple months ago it didn't have search. Which made me uncertain how people use terminals without built-in search. It really surprised me that it apparently was so low on the must-haves list that it took over a year to have it. I think I search terminals multiple times a day when I'm operating production systems.
I loved Ghostty for thr first month I tried it, but got some strange behavior when SSHing into some machines. Sounds like this release may address that. Maybe I can finally ditch iTerm2, lol
It’s rude to install a terminfo on a remote machine (which you may not be the owner of). It’s a preposterous for a terminal emulator to install things on a remote machine just to make it work.
It's actually the remote machine that isn't working, but I get the frustration. What I did to fix this is to override the environment variables in your SSH config like this:
If you want to use in a terminal emulator features that do not exist in any xterm variant and the remote computer does know only xterm, there is no way to do that without installing data into the terminfo database.
Otherwise, there is no need to install anything, you should just set the environment variable TERM in the remote computer to one of the xterm variants and then modern terminal emulators like kitty or ghostty will still work fine, but of course only as long as you use the xterm-compatible subset of their features.
It's not a VAX that you're physically plugging a terminal into. The remote machine is totally capable of communicating with a newer terminal, it just needs to know how. You're being nice by giving it that information. You can also just install it locally in your home directory (~/.terminfo). (You used to be able to stuff the entire entry into the TERMCAP environment variable and not install anything.)
Yea unfortunately eg Ubuntu’s bashrc has a script which will make it drop colors regardless of the presence of ghostty’s terminfo. Its `screen` will also fail, so e.g. it will refuse to upgrade to a new distro release.
Every terminfo is custom, to the terminal it applies to. It's just that most entries are 20+ years old and even glacial distros have converged on some version of the database that mostly worked, until the recent resurgence of interest in actually writing new terminal software.
I'm still using Wezterm here due to its Windows support, and I like being able to share one configuration my company Windows and my personal Linux laptops.
I've come to like its hyperlink rules to automatically generated clickable links to Reviews/Issues/Requirements/Linter Errors/... so I haven't felt the need to switch yet to have this feature missing.
I use ghostty as my go-to terminal on my linux devices. I chose it after trying four or so with the way I work. It just works perfectly for me.
But I only really have one use case:
1) Work the way I want it to
I could list my wants as an example, but there is no point because I don't know whether my needs are being met by what they consider a mistake in their design or a feature they provide.
So you can understand my conundrum - am I relying on features and design they consider is broken? If so, my current set up will "break" for me, even if it is a measurable improvement for most other people. I don't know.
I have no reason to "fix" the "working" release for me.
This is meaningful when forced upgrades occur, because the cost of training is never borne by the software provider (looking at you, big 4 or 8 or however many there is now.)
I don't understand complaints like these, the tool is open source, fork it build it yourself and you will never have to update it. You really have the power to maintain your own tools.
My experience with terminals was like this - Alacritty -> Ghostty -> tty7. The last one implements exactly what I had in mind when I used Alacritty and Ghostty. Only it doesn't hype much (the author apparently doesn't strive for that much), maybe that's for the better.
A bit dismissive, I'd say it's a defensive statement because pretty much everything posted on the internet with a comment system will have an "Is this AI? I can see from some of the pixels and having seen quite some AI in my time" type remark.
ghostty vs xterm.js (the VS Code terminal) - obviously ghostty is going to have better performance, but I just have never hit a performance limit in the VS Code terminal. I don't understand the demand for an ultra-accelerated terminal engine, but it's so popular it must be something i'm missing...
I'm using xterm.js with the canvas/gpu renderer in my app, driving these modern coding agents that seems to use every features in the book of terminals and it's perfectly fine.
The dom renderer is also perfectly fine, just needs a little bit more careful CSS to make it look right with some of the fancy line art.
I do use ghostty and it's alright. It's required for some rich TUI ai seems to be pumping out. Otherwise I prefer tilix and the default gnome terminal, but it might be just because of years of habit.
Normally not a fan of appimages, but this group focuses on making higher quality versions that make very few assumptions about the host system and work almost anywhere. While also prioritizing speed, small sizes, and up-to-date dependencies.
The Ghostty bandwagon is pretty loaded up, but iTerm is still where it's at. Recently saw some work on some iTerm work for multiple platforms from someone and it looks like it will work. Pretty excited about iTerm on Linux and Windows.
iTerm on linux would be the dream! I wanted to switch to ghostty for the performance and sane defaults, but it’s just not feature complete with iTerm yet
Are the context menus hardcoded? Ghosttty is the only app on my machine that uses those horrendous rounded context menus, and because I don't use a compositor, they also have a giant black band around them. None of the config file settings seemed relevant, but maybe I missed something?
window.zig: widget.addCssClass("no-border-radius") when no compositor is detected seems like it should be preventing this, but it's clearly not working.
I've been a laggard in switching to Ghostty because I used WezTerm and wrote a plugin to customize it to my liking. I switched to Ghostty just because I got tired of nothing happening in the WezTerm land and wanted to try something different.
Same boat here. This makes me think I’ll switch to ghostty soon
How’re you feeling after the change?
Got the Rex beta but haven’t looked at it really. I made a custom Claude code harness that is orchestrated by go CLI Claude wrote for me and that uses herdr for session management. Probably there’ll be something interesting I can do with Rex in the future as an alternative
I have quite enjoyed using the kitty image protocol in interesting ways.
I made a Claude code skill telling it to put a little image in the corner of the console when it does a render to see how something looks. It was quite fun telling it to draw a chicken with 5 SVG D paths and watching it iterate in the terminal.
Kitty is so awesome. I'm writing (well, as much as anyone writes) a MUD that models a decent part of Tokyo at 30-60fps over SSH at reasonable resolution (that's the dream, at least). I'm shocked at how fast I can render a big complex 3d environment, in the terminal.
Glad for an update. It’s unfortunately still missing table-stakes features for people who use primarily keyboard driven workflows. I guess I’ll stick with wezterm for another year.
Judging from kitty benchmark, 1.4 is much faster than previous version 1.3.1. Vivido[0] was the fastest terminal when i measured terminal performance a month ago. Now Ghostty is the fastest. Time to catch up.
> Escape codes are the new html for browsers now called terminal emulators.
Not really and that isn't a good thing in the long run.
There should not be any more complexity in a terminal emulator that will just lead attackers to craft RCEs exploits to your terminal to steal your secrets on your computer just because "Its cool" and has hundreds of escape codes.
I tried Ghostty for a few months, but found that it had the slowest launch time of all the terminals (NixOS) - we're talking seconds instead of tens of ms. Sadly, it looks like the launch improvements here are for macos.
I'm on Rio at the moment, pending a wezterm bugfix (but I might just stick to Rio). The launch is perceptually instant on all my machines, and it does support sixels and all that nonsense.
The update experience in Ghostty is great. I think it takes under 5 seconds from the moment you click accept update and until the new updated terminal is running.
If I am not mistaken, this is like another iTerm-like app. These tools have access to the innards of your system, like a VPN tool with access to all your connections. How do you trust, or build trust with, tools like these? How do you know whether the actor (s) behind them have malicious intent? Do you always build from an open-source project yourself? Is it a solution or the solution?
I use suckless terminal because the entire terminal is 4888 lines of C (including comments). Builds immediately. Starts immediately. Does everything I need it to do.
Have several running; resident set size between 10MB and 19MB.
Start with the person that is instrumental in this - Mitchell Hashimoto - you probably use products built on top of or with his tooling somewhere in your daily life already without knowing it. https://mitchellh.com/
I suspect you're getting down voted on this as it feels like this is a failure to educate yourself on something that feels like it should be relatively easy to do so in less time than it took to type your message.
I'm sure mitchellh will check out this comment section at some point - any updates on the move away from Github? I don't really see anything that's changed, but maybe it's behind the scenes. I was pretty excited on your initial post about it but it's been a while.
My biggest gripe with Ghostty is that on Mac, window state restoration doesn't remember the previous contents of the terminal, only the working directory. I've been meaning to switch back to iTerm2 over this, but just been lazy. It can be difficult for me to remember what a tab was used for just based on the working directory.
Hmm I wss checking for updates last night actually. I really hope they dont start adding llm junk to ghostty. I really like it, but mitchel sounded like he got bit by the llm bug a few months back.
Its honestly perfect as it is, just nerd performance tweaks imo.
Truly odd to see this comment. For me, mitchellh defines the moderate position on agents in coding, I mean that seriously: not occupies it, defines it. I’ve raised this point in discussions and others get what I mean without explanation. He’s better known for a mitigation to LLM downsides (vouch) than for making conspicuous use of them, and insists on human-only prose in issues, PRs and ‘real’ documentation (which I firmly agree with btw).
He also has a blog post and some tweets about how they can find and fix difficult bugs, and otherwise are capable of solving hard problems now. Well, they can.
An LLM may be fine to implement quickly an application that more or less works, but I have not seen any evidence that any of them is able to write well optimized code, whenever the application is not just a duplicate of something older.
Ghosstty and a few other newer terminal emulators are not only lightweight, but they also implement very fast GPU rendering, which is one of their important advantages.
So not only their set of features matters, but also the achieved performance.
Of course, one could use an LLM to write a very fast terminal emulator, but for that a competent programmer must be included in the feedback loop, which would require many iterations and running benchmarks and emulation conformity tests. It cannot be done by vibe coding with a prompt like "write a lightweight terminal emulator".
I've reimplemented ghostty in Rust and it performed on par with ghostty.
I've also given various models access to the tools necessary to measure performance and instructions to make things faster and they do pretty well. Hill climbing on a validatable measure is reasonably easy these days.
My direct experience here directly contradicts pretty much everything you've said can't be done. I.e. the human out of the loop stuff.
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 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!
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).
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.
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!
"One almost forgets how easy it is to read a wall of text when it was written by a human. "
Erm, this really depends on the human I think.
They should train AI for this, God it would help.
you mean you don't like phrases like "here’s what they don’t tell you" !?
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.
But I can't do this any longer. I'm tired, boss.
You were right to call me out on that.
And the real load-bearing part? It's not that, it's this. And honestly? That's great!
Lowkey so true. I was wondering why I was able to read to the end without getting lost or distracted lol
When I am tired, it's when I know I am alive.
what a great quote.
here's another:
"when i am sad, i have to remind myself that sadness i feel so as to qualify me to enjoy and feel joy."
this is not mine, it's a paraphrase of a poem verse from Mawlawi (aka Rumi in the West).
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!
Ooooo, will this end up in Konsole / konsolepart? Or will it be a new app?
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.
Surely you know konsolerc is text-based, right?
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 )
As a fairly recent ghostty user I was surprised with how quickly it became my default terminal. Very smooth experience so far.
Thanks for the work on getting libghostty 1.4 out! :D
Wanted to add too that I can't wait for xterm to eventually support libghostty, you've been super supportive providing feedback!
https://github.com/xtermjs/xterm.js/issues/5686
That's xterm.js. Xterm is an entirely different piece of software.
> Libghostty now builds and is tested (in CI) for: [...] freestanding (i.e. direct on hardware with no OS).
That's really cool, but I'm drawing a blank; what's it used for? Embedded terminal something?
Yep, fun little demo: https://x.com/UzaAft/status/2093774764598817022
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
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.
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.
It's a pleasure reading your posts.
Is it feasible to implement the libvte surface on top of libghostty? Might be interesting as a drop-in replacement.
Maybe I’m just dreaming here but how far off is libghostty for Linux consoles?
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.
But if you run nix you could give it a whirl: https://github.com/KritR/ghostty-kms
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.
Awesome, great going Mitchell! And Ghostel, which I'm hearing of for the first time, sounds very exciting.
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?
Interesting! Have you looked into variable-axis monospaced fonts at all for this project?
https://monaspace.githubnext.com/
What's the rough approach? Do you support mixed fixed/variable, like could an editor show mono for code and variable for prose?
How do you know it's supposed to be columnar? Would you have a screenshot?
Absolutely incredible. You've convinced our team to start getting to work in Zig and we're loving it!! Thanks for all you do
I know it’s been said elsewhere ITT, but thank you for making and supporting Ghostty!
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.
Use tmux or something like it (I now use zmx[1]).
[1] https://github.com/neurosnap/zmx
I am not interested in workarounds.
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.
Great stuff! If it wasn't for Rex I'd still be using Ghostty daily
Aha, I wondered why the JetBrains terminals had become so much better recently. Didn't realize they'd made the switch.
Thank you for libghostty! I'm using it for my own terminal on Windows. I'm quite pleased with it
Curious which terminal is this? I've been looking for a Windows terminal app which uses Ghostty.
But could it do two rows of tabs?
Thank you for making Ghostty, it’s a pleasure to use it everyday for work :)
Is the launch timed for Halloween parties? Good job team + community!
What are use cases of libghostty? Is it for building things like the terminal inside VS Code or any other such GUI application?
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?
As a first-party remote solution, I've been playing with the beta version of Rex (https://www.superlogical.com) and its remote access is pretty slick!
I am fiending for an invite to Rex. I hope I can use it to replace my Paseo workflow!
rootshell is libghostty and free, doesnt strike me as vc backed
Hello Onavo. Cosyra.com is not venture backed and not a ghostty wrapper! Lets you remote control all your agents from your phone without SSH.
Isn’t it written in Zig? Not sure how that is “highly portable” compared to C
From https://ziglang.org/intro/overview/
What does that have to do with portability? It doesn’t support a bunch of CPU architectures, the portability metric I care about.
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.
I/my agent somehow integrated it into a C++ app on Windows. So one way or another, it does work.
Zig is even more portable than C
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
Is it? I think zig use llvm codegen. Once you got llvm for your architecture, you get 99% of modern language
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
Certainly parts of terminals protocols are archaic, but overall it's not nearly as fragile as you make it out to be.
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
> 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.
When you say you've proven, are you hinting at use of formal verification?
Here, "proven" can be read as a synonym for "demonstrated".
the web version powers our quickstart via a cloudflare websocket and some custom patches (only on desktop): https://hotaisle.xyz/quick-start
it is all open source: https://github.com/hotaisle/hotaisle-website
Why is libghostty better than alacritty?
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)
I am pretty sure that Mitchell has addressed the matter in previous blog posts.
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.
I've tried Ghostty and it's great, but Kitty's hints mode[1] is the one feature keeping me from switching from Kitty to Ghostty. There are quite a few discussions around this and similar features in the Ghosstty-org/ghostty Discussions[2] which I follow. Most of them are references from ghostty-org/ghostty/discussions/2394[3]. Maybe now that Ghostty has finished implementing Kitty graphics hints will be next .
[1]: https://sw.kovidgoyal.net/kitty/kittens/hints/
[2]: https://github.com/ghostty-org/ghostty/discussions
[3]: https://github.com/ghostty-org/ghostty/discussions/2394
How have I not heard of hints mode before, that is amazing. Thanks for pointing it out I need to go remember some new hotkeys now.
Definitely stealing those hotkeys for my own terminal emulator! Was wanting similar functionality but wasn't sure of the shortcuts to use.
Yeah this is what is keeping me from using ghostty. Unfortunately I think that discussion is dead and no one agrees on the design of the three or so separate parts. I maintain a fork with quick select for my own purposes but I can’t use it at work.
BTW here is my fork: https://github.com/Grazfather/ghostty/tree/quick_select
Far from perfect. No way to bind to specific action:regex pair, so `ctrl+o` then `y` will show hints for both urls, which it'll try to open, and git hashes, which it'll copy to the clipboard.Oof, I've never heard of that and it sounds amazing
Hints Mode, yummy. That would be nice.
See like something that can be handled by the multiplexer?
I'm thinking the same (e.g. extrakto). Am I missing something?
I still don't understand the point of Ghostty, Kitty, Wezterm...
Konsole is way faster than any of those on my computer and it has all the usual suspects I'd expect from a modern terminal emulator.
The one feature I miss since moving to Linux and not having iTerm2 is tmux -CC integration. None of those offer it.
To be clear, I'm not attempting to be dismissive. I really want to understand what it is that they bring.
KDE guy here.
Konsole is a fantastic and very mature terminal emulator, but it does have some real gaps that reveal its age.
The Qt toolkit that most KDE software is based on at some point introduced a next-gen toolkit-within-a-toolkit called Qt Quick, which most of our newer apps are written in. However, in its library form Konsole can only be embedded into apps that use the old gen toolkit. This is a real impediment to some efforts.
The old gen toolkit also typically doesn't use Vulkan or OpenGL for rendering (the new one supports both), and so Konsole's terminal renderer doesn't either. Konsole's real-world performance during use is arguably just fine, but it does leave a lot of performance and battery life on the table.
libghostty also has somewhat wider support for newer stuff like Kitty protocols, even though Konsole certainly trumps it in support for older stuff (like sixels).
There's some other shortcomings to Konsole that are not inherent to the technology, like accessibility support not quite being where it should be.
And while the default UI is, in most distros, OK, there sure is a lot of spiderwebs and spacebar heating lurking in the settings dialogs (of which there are strangely many). It's also a bit dated vs. our HIG at the moment.
Which is to say, these projects can and do have a point, especially if they provide a nice library instead of hoarding all the good to themselves.
A couple of annoyances I've had shipping CLI apps to Konsole users:
1. By default, Konsole disables OSC8 link support. Users can enable it manually, but you need to ship fallbacks by default since otherwise the default users will have a broken experience. Ghostty, Kitty, WezTerm, etc all ship working OSC8 support out of the box.
2. No built-in Nerd Font support, so if you want to render icons, you need to tell your users to set up a patched font or else have fallbacks. Ghostty and WezTerm ship built-in Nerd Font fallbacks if your configured font isn't patched.
That being said Konsole is much better than most emulators. iTerm2 is not bad, although it lacks Symbols for Legacy Computing Unicode support (which all of the above have, including Konsole, and which is very useful for drawing prettier terminal UIs). The worst by far is Apple Terminal, truly the IE6 of terminal emulators.
What's so bad about Apple Terminal? I've tried iTerm2 and others but never found a compelling reason to use them over the stock app. I don't live in the terminal like some do, though.
Apple Terminal doesn't support:
1. The Kitty keyboard protocol, which makes it impossible to distinguish e.g. Shift-Enter from Enter
2. OSC8 hyperlinks
3. It breaks on APC queries, so you need special handling to not emit them
4. Symbols for Legacy Computing Unicode support
5. The Kitty Terminal Graphics Protocol (or sixel)
6. OSC 9 notifications (or any of the later versions)
and a bunch of other stuff, this is just off the top of my head. For a long time they didn't even support 24-bit color, although they fixed that in Tahoe.
It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.
> It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.
The latter seems always to be about aesthetics, not about UX.
> By default, Konsole disables OSC8 link support.
That is, in my opinion, the correct default.
I believe that the default behavior should be to never open a link without a confirmation from the user that this may be done.
This should be enough to avoid malicious links. I do not believe that completely disabling links is a good default, because they are very frequently useful when you read some text file in the terminal window.
Yes, I agree. Ghostty et al don't open-on-click, but on hover they'll show you the URL and there's a keyboard shortcut + click to open. This is much better UX than disabling OSC8.
Yeah, because more complexity where you don't expect it doesn't cost anything?
Up until 5 hours ago this fix was not present:
> The displayed target is sanitized so invisible and line-breaking characters cannot conceal the effective destination.
https://github.com/ghostty-org/ghostty/security/advisories/G...
The sensible default is to have it turned off. And by the looks of it Ghostty versions before this you couldn't even turn it off.
"One implementation of a feature had a bug, therefore this feature should be turned off on all implementations by default" is probably not going to convince people who think the feature is good.
If you don't want to be able to have clickable hyperlinks, by all means use Konsole — no one is forcing you to use Ghostty. But if you want to know why people like Ghostty's approach vs Konsole's, it's because Ghostty pushes terminal emulator features forward and is low latency. Konsole is low latency and adopts some but not all features that other people invent. It's a noticeable difference and so people who like the feature part of the former like Ghostty/WezTerm/Kitty more than Konsole. If you don't care or dislike that part, and want a more conservative terminal (that is also low latency), Konsole and many others further on the conservative spectrum exist.
It’s not just one implementation. Browsers have been struggling to get this right for decades and now we are destined to repeat all the same problems all over again with an entirely new syntax of inlined markup.
Bugs are fine, but this wasn't really a bug. It was lack of foresight.
I haven't used Konsole, but I do like this "recent" focus on terminals and have used many of the newer ones. Dailydrived st,alacritty,wezterm,ghostty,kitty,foot (probably forgot some) and I live for the regex pattern matching copy shortcuts etc.
I learned about OSC8 because my terminal (whichever it was) used one of its features and I didn't know it was possible to do that. My immediate thought was, how is the security?
And it is very disappointing to see how little effort people have spent on that. That is really one part that I expect more from modern incarnations of the old terminals where I can sort of forgive them for the lack of security posture.
I like ghostty, I really do. But this is not a good look, and to be clear it isn't just ghostty. Without looking for it I've stumbled upon several OSC8 and OSC52 bugs (in other software) recently.
I don’t want random text in my terminal to be a link. I do not find that useful.
If people want it enabled, they can enable it. It shouldn’t be the default.
Surely you realize most people would disagree?
Most? Probably not
Someone? Almost certainly
Congratulations, don’t use Ghostty or terminals built on top of libghostty and you don’t have to!
I don’t. But the problem with OSC8 is it opens up whole new vectors for security vulnerabilities in an application that is, by intent, used for some of the most security sensitive work in our jobs.
I wouldn’t mind OSC8 so much if it had proper security auditing but it doesn’t. The whole thing was pushed by one guy on a GitHub gist who blocked anyone who dared discuss security issues.
At least with browsers, you have masses of people testing these things. But there’s no rigour to any of the tests that happen with terminal emulation. Let alone independent security audits.
And at this rate, it’ll only be a matter of time until we see “don’t cat untrusted READMEs” advice because they might contain boobytrapped escape codes. Which is an absurdly bad place to end up.
1) Personal preferences: different terminals come with different defaults, some people do not want to tinker with the settings, so they just stick with whatever immediately clicks.
2) Technical curiosity: some people probably started their own terminal project just for the fuck of having made their own - and they eventually gained a userbase.
3) Feature set: Most terminals implement most features these days, but at the time these projects started, you'd have a feature matrix between features and terminals because most terminals lacked some features; so people would pick whatever suited their needs.
Personally I've been using kitty for years mostly due to 3), at the time I chose my forever terminal, I evaluated like 12 different ones, and kitty was the only one that covered most of my needs without feeling like it suffers from random quirks, and I like that it has built-in terminal multiplexer (a'la tmux) and emoji picker.
The terminal ecosystem needs to change, and these terminals support a lot of cool features. Ghostty's pure reusable terminal state machine being a source of truth, Kitty graphics, Wezterm and its mux domains & lua config, lots of cool ideas there.
Having having an industry player like hashimoto's superlogical driving terminal features is the extreme version of that
> Ghostty's pure reusable terminal state machine being a source of truth
Can you please explain what this means? I have Ghostty installed just as a backup to use when I have terminal saturation in my default (MacOS Terminal). But other than being super responsive, I don’t know why people love it so. Perhaps I’m missing something large and compelling.
I assume the quote is referring to libghostty. In which case a lot of different tools like vs code, Emacs, Gvim, Intellij and other IDEs, even web consoles on stuff like Azure essentially use and reimplement the same core, the idea behind libghostty is to replace those with a common component where long term development can better support the needs of all terminals.
In terms of ghostty itself its just a highly competent use of libghostty, Mitchell’s message above about it being a tech demo is tongue and cheek, but its not far off from the truth. It is just a really solid no bells and whistles, bar excellent execution, terminal emulator that uses libghostty.
Terminal state machine parsing is a very tricky thing, especially when you have people defining arbitrary protocols to interact with it. So having one implementation simplifies the development a lot. Of course this buys you into their ecosystem and whatever ghostty specifically supports etc.
A lot of other terminal emulators can expose similar reusable things (alacritty comes to mind) but libghostty is the most well supported one
It being super responsive is the reason I switched to it. MacOS terminal had issues keeping up with Claude Code. It would frequently be super slow rendering the text output or sometimes just stop altogether.
When looking at options I looked at speed and simplicity. Ghostty fit the bill but I did evaluate iterm as well. Excellent terminal but too many features for what I was looking for. I live in the terminal but am not a Terminal App power user if that makes sense.
So, it really comes down to what you want and what your workflow looks like. Ghostty has been flawless for me the past 9months. It gets out of the way and just works really well.
Really? Claude Code is buggy but not very demanding in terms of rendering -- are you sure the perf issues were local?
The issue the OP mentions was likely a known memory-leak in Ghostty that has since been fixed. Claude was triggering the bug in Ghostty but the bug was in Ghostty. Ghostty's author blogged about it
https://mitchellh.com/writing/ghostty-memory-leak-fix
I might not be using the correct terms. But, here is what I was seeing:
- in a running session text display would slow down intermittently. Like 2-3 words a second
- occasionally terminal would stop, some times in the middle of showing a response, and would need to restart the terminal to get it back. But I tailed the session logs and Claude code didn’t think anything was amiss. It was proceeding like normal
After switching to Ghostty these issues went away and has been rock solid since then.
EDIT: formatting
Why would a terminal multiplexer need an entire company behind it? Especially since it looks identical to the many other vibe coded alternatives (including my own lol).
> The terminal ecosystem needs to change
What is your justification for this statement? Why does it need to change, and what does it need to change to? Personally, I've not felt this (and I spend a lot of time in the terminal). Fish shell and Byobu give me everything I've ever wanted.
Like the poster you were replying to, I don't understand what these new terminal emulators bring to the table, other than potentially more resource usage.
I feel that there's something here that I'm missing (ghostty is clearly popular, so it must bring something both new and useful to the table), but I'm genuinely not sure what that is.
I assume that this depends on your computer/GPU/GPU driver.
I have used Konsole for many years and I have used kitty for about 2 years in 2024/2025, then I have switched to ghostty around the beginning of 2026.
At least in my computers (with NVIDIA GPUs and Gentoo Linux), kitty was many times faster than Konsole and Ghostty even faster.
Moreover, in the now somewhat distant past when I was still using Konsole, it did not have some font rendering features that I desired, but that might have been solved meanwhile.
A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window, which happened frequently with all terminal emulators older than kitty and ghostty (I have always used CPUs with enough cores so that compilation itself is very fast, so the older terminal emulators become the bottleneck).
Real question: Is the Linux kernel terminal the fastest of all? If yes, why not compile there?
I know for many folks they like the fact that it is cross platform (works on mac/linux) etc and gpu acceleration which is really nice to have.
Yeah, I recently tried out Kitty and Ghostty just feels much smoother when rendering most TUIs and even some more basic stuff like the homebrew progress bar. It is also better about respecting platform conventions for things like keybinds and window/tab behavior.
I have been using Alacritty for its GPU acceleration long ago. Ghostty was slightly faster, but then Ptyxis was also faster. Since I preferred to configure my terminal with GUI, I have switched to Ptyxis.
For me: it doesn't really "bring" anything more than what I expect from a terminal.
In Mac, we had the default terminal app which has some problems with TUI apps and other small issues. iTerm2 is the replacement that most users use, but it become too bloated with useless features and AI, while it was hard to keep a good config file that I could share between devices. Ghostty was a sane mid-term for me: a good and modern terminal, with a simple config file, maintained by someone that I trust (Mitchell Hashimoto) and only that.
About Linux: I don't use Ghostty in Linux because I'm comfortable with Konsole.
There's always gonna be something that's better, faster, bigger, badder, stronger, thicker, firmer, etc., and terminals really aren't one of those things where I am interested in exhaustively testing all of them to find the truly greatest one. A terminal is also one of those things where if you find one that is perfectly adequate then there's little motivation to even bother using trying one. And there's the whole "devil you know" aspect. The only reason I rarely try a different terminal is if the stock terminal on whatever OS I'm using lacks some basic niceties that should be expected in the year 2026.
I like Ghostty because I find it both fast and configurable, and it's multi-platform without treating macOS like the red headed step child. I also appreciate how its configuration is text-based, which I prefer to someone's opinion of how a configuration GUI should behave, and I think it's good the developers aren't wasting a second of their time thinking about a configuration GUI.
Funny, I won’t use a term emulator unless it has a good GUI config. Even SGI and Windows Command prompt had them in the 90s.
Also the konsole context menu and default toolbar are a mess.
I also thought like that, but you only to set some defaults and you're ready to go. If you still prefer a GUI there are online generators. Nowdays you can also vibecode them, they are very simple and any LLM will do it right
If you have to see them, they aren’t defaults. It’s bad enough that Windows Terminal doesn’t expose its full configuration and forces you to edit the config by hand for more advanced stuff. Feels like a step backwards when something like iTerm 2 gives you access to all settings in a (admittedly kinda crappy) GUI. This also kinda begs the question why there’s not a /TUI/ configuration manager shipped…
There are mature emulators for decades now, why go backwards? I guess there are a few tiny features that might be useful, and am open to them. But a new project needs to be strictly better, not two steps forward, one step back.
Ghostty is getting there though, and today is a milestone, not complaining too loudly.
The lack of a config GUI in ghostty used to bother me, but to be honest now I just describe to Claude what I want to change and it does it. It would still be nice to have one eventually but I can see the argument for deprioritizing it.
I tried a bunch of terminals and ended up switching back to xfce-terminal, fastest I have tried by far. (It's just the default that ships with my distro.)
Actually I think xterm was even more performant, but the eye sore wasn't worth it for me.
Also in the xfce camp. KISS
I use Linux at home and Mac at work. I use Ghostty simply to have the same terminal on both systems.
Me too. I was using WezTerm for a while for the same reason.
It wasn’t the only reason I switched, but I prefer config to be config and code to be code rather than my WezTerm config to be executable.
I don't think Konsole is actually faster than Kitty or Alacritty. Kitty is really nice and an innovator in a lot of terminal standards. It's also non-commercial and not related to any sort of startup (not that Konsole is either). It's definitely my first choice of the bunch, followed by Alacritty.
Konsole seems to keep up with modern features as well. For instance I realized yesterday that it renders the newer progress codes that clis can emit. I am content.
For me it's simply that iTerm2 got really fat over the years, and Ghostty was a nice and slim alternative - plus it has one of the better Kitty Graphics Protocol implementations which is fun to tinker with. e.g.: https://github.com/floooh/chipz-kitty (needs zig-0.17.0).
> chipz-kitty: Emulators in terminal experiment.
Cool! How fun, I'm a big fan of your work and will enjoy learning from this project too. (:
For me, the main reason to use Ghostty is simply that mouse support works right out of the box. In Konsole clicking a spot to move the cursor only works if you're using Bash. While it also works with the Fish Shell on Ghostty.
Same here. ghostty + fish = just works out of the box, no plugins or dotfiles needed. Plays well with accessing remote tmux claude/codex sessions as well.
To add to the other good points made in sibling comments, MacOS has butchered fullscreen to the point where some of us depend on MacOS terminal emulators having the "non-native fullscreen" config option. Personally, Ghostty does the best job supporting my preferred terminal environment of non-native fullscreen with tabs that works with an auto-hiding menubar and the camera notch.
The other day I was able to click on Ghostty, then open Gnome Terminal, type a command and run it before Ghostty had finished loading.
Yeah. It's slow on Linux, for sure. I use Foot, which as far as I've tested is the fastest to launch. I use Niri and launch Foot terminals all the time as part of my workflow (it's just how my mind works), so time to launch matters to me.
Monstar is a libghostty derivative that resembles foot: https://github.com/rockorager/monstar
Namely it is wayland only, cpu rendered, and doesn't have any window decorations
Yep, same here but with xfce4-terminal.
I've just reverted back to using that as it's faster to load and has all the features I need.
It works well, that’s my only requirement. I could ask you the same, what’s the point of Konsole, what value does it bring?
You could, but my answer would probably skew your opinion about as much as yours did mine. :D
To me the point of Konsole is that it works well, plus it's already there. Ghostty I need to make an effort to have it, however small it is, and I'm just trying to understand what I'd be missing if I didn't.
Konsole is not already there for me. I would have to make an effort to get Konsole, just like Ghostty. I’m struggling to see what point you are trying to make. Do you want someone to tell you Ghostty is better than Konsole to convince you to switch, or … not?
Cross-platform native GUI, built-in nerd font symbols. Simple text file configuration with trivially easy platform/machine-specific drop-ins.
Seems a bit of a disingenuous comment when you initially said "I still don't understand the point...".
Surely you understand Konsole is not already there for most people?
This days I don't really care about the terminal I use. It's xterm on OpenBSD, konsole on Fedora KDE, terminal.app on MacOS,... As long as I can use cli and the few TUI software I use.
Kitty is really nice, a programmable terminal that does everything I want, GPU rendering, etc. Haven't used Ghostty yet but one of its advantages is libghostty, modern terminal emulation as a library.
> libghostty: a cross-platform, minimal dependency library that exposes a C API so feature-rich, correct, and fast terminal functionality can be embedded by any application anywhere.
Oh the author actually posted about it just now in rich detail. It's pretty exciting for people who spend much of their time in the terminal.
>I still don't understand the point of Ghostty, Kitty, Wezterm...
WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.
That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.
iTerm2 feels overwhelming to me. I think the default Terminal.app is good enough.
for terminals I personally am using kitty, but libghostty is great and powers ghostel in emacs which is amazing. Also note if you start trying to look at unicode correctness, in my experience ghostty is in general the best among all alternatives.
> Konsole is way faster than any of those on my computer and it has all the usual suspects I'd expect from a modern terminal emulator.
Same boat here, though I also get to enjoy some of the benefits of libghostty, via ghostel in Emacs. Ghostel is noticeably faster when there's a lot of output being dumped, but I don't often need the speed and use it only because it's integrated rather well into the rest of my Emacs.
> tmux -CC integration
If you can stomach Emacs, there are at least two packages that implement this, one via eat and another via vterm, though none via ghostel just yet. Shouldn't be difficult to port, though.
I don't know about the others as I used Terminal.app on mac since Panther, but Ghostty has been a pretty good upgrade, at first offering 24-bit colour which Terminal.app didn't have at the time of its release. I also like the shell integration such as easy selection of command output. I don't ask much from a terminal as evidenced by using Terminal.app for almost 2 decades, but Ghostty has not once been an issue and is 'invisible' to me.
vouch this comment since this is a pretty common question people have, I don't believe it should be dead.
I do believe it should be dead
The advertised point is it needs zero config to work outside of the box. For example nerd fonts are included by default whereas you need to install them if you are using let’s say iterm2.
The point for me is each one can have ten or so claudes, so any one crashing doesn't take down all the claudes ... and I don't have to learn tmux.
Can konsole do the fancy shader and inline images? I think that's all that distinguishes the others but I may be overlooking things.
I have no idea what that is or why I would want it.
I'm not sure why you want shaders, but if you use a coding agent in the terminal you definitely want image support. Otherwise it's very hard to see what the agent is seeing.
I can use Ghostty and use the same featureful terminal on Linux and macOS.
I also hate configuring Konsole, most KDE apps for that matter. Being able to have a plaintext configuration file I can keep in my dotfiles is way simpler.
tmux control mode (-CC) is the killer feature I'm waiting to land in ghostty
Konsole is not gpu accelerated and is several orders of magnitude slower as a result than those that you listed?
The acceleration is the primary point.
I don't know Konsole, but kitty have tons of features other "plain" terminals lack. It's not just about speed (which I never got the obsession about either)
Ghostty is so much better than iTerm2! Don't get me started...
I'd love to, I switched back to iTerm after not really feeling any big difference in my uses cases, but also hating the crappy plain text with no defaults listed config that required me to use a goddamn web app to comfortably learn and fill out.
There was also some pretty noticeable differences in character rendering between the two with identical-as-I-could-make-them font settings.
> here was also some pretty noticeable differences in character rendering between the two with identical-as-I-could-make-them font settings. I'm pretty sure it was iTerm's problem.
I've tested a number of Terminal Emulators on macOS and Ghostty's rendering is always superior.
You should give 1.4 a try.
It just works. — Steve Jobs
Ref: https://arne.me/blog/we-need-more-zero-config-tools
Yeah except when it doesn't. I shouldn't need to reference documentation to change my terminal font.
Honestly, iTerm's settings were always a mess in my opinion.
I feel like good tools should be invisible and Ghostty's lack of fully fledged Settings app is a feature, not a bug.
Just open it in Kakoune/NeoVim and change with a speed of thoughts. Never used any third-party Settings apps though.
Ref: https://news.ycombinator.com/item?id=48858121
Change with a speed of thought
Yeah, except the default config file doesn't EXIST and there is nothing but the reference docs to tell you what the hell you're supposed to put in there. What am I supposed to do, guess? Is it `font=` or `font-family` or `font-name`? That's fucking terrible. The very existence of a website like this: https://ghostty.zerebos.com proves the failure in my opinion.
Good tools should be invisible. Good tools behave the way I want them to. That's different than the way you want them to behave. Or appear. Good defaults are good. That is absolutely no excuse to abandon good UX for configurability.
I'm happy the defaults work for you. They don't for me.
And don't get me wrong, ghostty is a fine terminal and I don't begrudge it, and I think libghostty is awesome, it's just not the application for me.
What do you mean “there is nothing but the reference docs to tell you what” valid configuration options are? Where would you expect that to be documented otherwise?
I would expect the default configuration (which does set keys to specific default values) to appear in my ghostty config file. If there isn't a UI, how the fuck am I supposed to know what the names of all of the keys are? How am I supposed to know what is even possible to change?
A brand new ghostty config is an empty file because it only shows you what the overrides to the default config are, which means if you want to change your ANSI colors, off to the docs to look up what they're called as config keys and what format it expects as a value. Want to hide the Secure Keyboard Entry overlay? Off to the docs to figure out what the key is called. Is it a boolean? Does it accept true/false, or only 0/1? Who knows! Go to some website and scroll and scroll and scroll and maybe you can find it.
Or they can just put 'macos-secure-input-indication="true"' in a file it creates when it launches for the first time and notices it doesn't have a config file in an expected location. It can put that in there and every other default setting it actually is setting for itself, instead of just keeping it all socked away in the compiled executable as a behavior. Show me, on the computer I have, in the file I'm supposed to edit anyways, what all of the possible keys are, and some general indication or hint of what the fuck I can put in there. Don't make me fetch it for every single goddamn boolean. I wouldn't need to open a fucking web browser to hide the secure input icon because I'm not stupid and could infer it from the default config. Oh I bet it's the 'macos-secure-input-indication' key I need to set, lets flip that to false. There's a limit to this of course, not everything is going to be immediately clear, and for keybinds it might be a little preposterous to have all of the defaults listed, but for setting my themes? Colors? Fonts? Basic shit? Don't make me work, I have better things to do, but I need to be able to read my terminal.
The lie of "zero config" tools is that they are absolutely NOT zero config. They are usually full of changable behavior and they just skip the part where they make it easy for you to figure out how to change any of it, because...I dunno...configuring your software to work the way you want is...bad? Sounds stupid to me.
I was sceptical for decades as well. But they are amazing - no more closing the xterm by mistake. I'm using those because I wanted for example a single window with THREE consoles open at once AND being able to handle some ANSI crazy theming.
Xterm failed me :( Tabby just works.
cute little mascots
Lots of things bother me about my terminal emulators, and it's almost always in the category of "things don't work right". It's never "I wish my terminal emulator ran faster." Ghostty seems hyper focused on speed, with the negative side effect that compatibility breaks - in practice. I get that it's following all the newest standards or whatever it's doing, but in reality it always needs custom setup to work right. And for me the net effect is that it's always creating problems, not solving them.
Man, still does not fix the one bug I care about: being able to quickly `⌘+F, ⌘+V` - the find textbox does not respect keyboard shortcuts: https://github.com/ghostty-org/ghostty/discussions/11159
I have a fix in my fork: https://github.com/ghostty-org/ghostty/commit/95c7fc322802a6...
Inspect + build yourself
I was really hoping a fix for this would be included in this release.
Why should I use Ghostty over iTerm2? I don't care about fancy fonts, iTerm2 speed (for me) is plenty (just tested against 1.4 -- don't see noticeable difference on MBP M1) and I do like to tweak some options/settings (and was just mildly annoyed when hitting `cmd+,` opened my default text editor...
The docs for ghostty's config file is a lot easier to reason about for one. The built in themes are IMO a lot better in ghostty.
Nowadays, it's also a more fun community. I end up learning things about terminal rendering I never would've otherwise just by reading ghostty-related blogs.
If you’re fine using iTerm just use iTerm. In my case I used iTerm for years and kinda liked it, but not completely. I’d been looking for an alternative for years but couldn’t find one I like (Alacritty doesn’t support pane splitting, Wezterm has full code config which I hate, Kitty doesn’t look good on Mac, Terminal.app is dog slow…). Ghostty just fits my needs pretty much exactly.
I am an iTerm2 user but I find its .plist config file a lot anachronistic and, if I may say so, quite absurd. I have tried too many settings and I still struggle with keyboard inputs getting trapped wrongly, lost, et cetera, the warnings that appear out of nowhere and I notice was wrong. But iTerm2 is the only terminal app that looks the best on mac (even better than the Terimnal.app itself) and somehow sits naturally with everything else around. I am sure for a lot of terminal users it might not even the last concern but for me it is. I tried Ghostty but I just couldn't like it. Kitty won't even be a consideration for many reasons (one is better off not discussed here). cmux is indeed quite good but it has become a HYDRA and will keeps on growing in every direction. iTerm2 would do great to keep the outer clothes and possibly adopts the base of something else. It isn't particularly snappy either. I moved back from Ghostty to iTerm2 even though I felt usage wise Ghostty was suprior. Ghostty just felt out of place.
I'm also very reluctant to switch and will not switch anytime soon. I have small compact tabs which I color code dynamically with iTerm2 and also custom profiles with custom keyboard keys overrides by program and directory. So the "harness" around the terminal is more feature rich with iTerm2.
These kind of features are not available in Ghostty in this form.
And about backups in iTerm2: Just do an export and maybe also a backup of your profiles. So that works.
I also do not care about a "super fast" terminal... my iTerm2 is fast enough for 99% of use cases for me.
> Just do an export
I have a feeling you already know this. You can direct its unnecessarily monstrous .plist file to a folder of your choice and that way it will remain synced and/or backed up all the time if that folder is. [General > Settings > External settings]
There is no reason. I switched from iTerm 2 and while Ghostty is a lot faster and lighter, it has occasional rendering issues and does not detect URLs as well. It also doesn't have tmux control mode which I really liked.
I quit using iTerm 2 because of the AI features. Ew.
I don't think anyone is trying to convince you you should use Ghostty over iTerm2. It's a technically excellent terminal built with an incredibly rigorous and well thought out guiding philosophy and a remarkable amount of passion. Nobody cares if you want to run it or not.
One reason is portability if you use (or plan to use) desktop Linux
I find iTerm2's constant prompts to update to be annoying. It has also crashed on me a few times. Lastly, I also prefer ghostty's text-based configuration.
For me even just the config format is such an upgrade that it was worth switching. Just a simple text file I can backup anywhere and actually read without clicking in a tabbed GUI where I never seem to remember what goes where. iTerm2 still has that weird thing you have to export right?
It’s subjective. The config format is a downgrade for me. The only settings I change is the color theme anyways. The terminal default should work well. It takes four seconds to use the mouse to open the theme config and pick a theme. It takes at least five minute to find the config file location, the syntax for the config file, understand whether it uses fs events to auto reload, and then decide to include or exclude it in your backups. I don’t intensely customize my terminal emulator so it’s not worthwhile. On the other hand my Emacs config is more than 500 lines long and that’s worthwhile.
I think you hit upon what bugs me about file config. It's not the file, it is having to find it, find the docs, find the syntax, find the keys, find the values, etc.
If it was always in a standard format, it wouldn't be a problem. Something like dconf, without the poor design.
Ghostty is so great. I am very thankful to Mitchell for dedicating so much of his time to making a terminal that is truly great. Finally, somebody really cares and has the technical abilities to materialize that care as great software.
Also, ghostel in Emacs is fantastic as well (of course in a big part thanks to libghostty) — most of my work has now shifted into Emacs as a result.
Good point, maybe letting talented people get FU money is good for humanity?
This depends on the individuals' character -- when I look around, I mostly see people who become jerks/a-holes once they get money. Especially in the tech world. Look at what Google founders do with their money (evading taxes, mostly), or at others who became outright nazis and support far-right movements across the world. In the best case scenario they just keep buying yachts and villas and stay relatively quiet.
Mitchell is a beautiful exception and it makes me happy.
It's almost like human creativity flourishes when not fighting for daily survival needs.
i tried ghostty, rio, wezterm, they all stuck for about a month or so... then the subtle usability issues become too much, and i wonder why i switched from iterm2 to begin with. there's something to be said for years of polish, and feature work that is well-baked.
iterm2 is fast, reliable, and second nature. i don't have to edit settings every day.
btw I used iterm2 for years as well and sometimes tried others.
I now use ghostty it’s faster definitely. Yes it has some quirks which is hard to overcome as a iterm2 user. But I could live with it. I think ghostty is basically also the only alternative to iterm2
While I'm not a hard core terminal emulator expert or tweaker, it was a bit of a learning curve to get into Ghostty after iTerm2. I hope this latest release makes it easier to edit the splits, haven't tested yet.
But the biggest thing that made me stay on Ghostty was that there's a freaking config file. With iTerm you had to export the profile and keybindings, and then import them on a new system which was clumsy, and easy to forget. Now ghostty.config is just one of my dotfiles, with a clear understandable git history, I love it.
There's ~/Library/Preferences/com.googlecode.iterm2.plist and it's always been there
Yup I switched to WezTerm from iTerm2 and being able to version control the settings is one of the biggest benefits (especially because WezTerm allows more complicated Lua scripts)
Why put up with quirks when you have something that works for you? How much faster ghostty is in practical terms?
I used iTerm and iTerm 2 for almost 20 years before switching to Ghostty full time in 2024 with minimal fuss besides the muscle memory of "cmd+space ite" switching to "cmd+space gho" to launch it!
Do you have specific examples of usability issues?
My main issues with ghostty: the global shortcut for quick window suddenly stops working and works again only if I focus ghostty. (On a mac)
The other one is quick window goes out of the monitor if i have disconnected and connected the laptop from minitor.
Another: sometimes autocomplete suggestions are shown incorrectly in some weird location (like middle of the screen, not at the cursor), again occasionally.
I actually fixed one cause of this, which is released in 1.4.0.
https://github.com/ghostty-org/ghostty/pull/12714
The only other cause I've encountered is if a secure input (password) field is focused, since macOS won't give apps global keyboard events for obvious reasons. If you focus a normal text input, it should start working again.
I have noticed where macOS doesn't properly release its reference to a Secure Input properly. I've documented how to determine if this is the cause here: https://github.com/ghostty-org/ghostty/issues/11883#issuecom...
Aha, this explains why I've never seen this kind of thing: I don't use quick window!
I'm happy with ghostty now too, but until a couple months ago it didn't have search. Which made me uncertain how people use terminals without built-in search. It really surprised me that it apparently was so low on the must-haves list that it took over a year to have it. I think I search terminals multiple times a day when I'm operating production systems.
AFAICT, the bug from 1.3.1 where you cannot paste into the search field is still present in 1.4. I guess agents doing all the grepping these days?
I loved Ghostty for thr first month I tried it, but got some strange behavior when SSHing into some machines. Sounds like this release may address that. Maybe I can finally ditch iTerm2, lol
Very likely due to ghostty setting TERM to xterm-ghostty and your destination not recognizing it. Quick temp fix is using the wrapper (ghostty +ssh), see <https://ghostty.org/docs/features/ssh>. More permanently, copy terminfo to the remote machine, see <https://ghostty.org/docs/features/ssh>.
It’s rude to install a terminfo on a remote machine (which you may not be the owner of). It’s a preposterous for a terminal emulator to install things on a remote machine just to make it work.
It's actually the remote machine that isn't working, but I get the frustration. What I did to fix this is to override the environment variables in your SSH config like this:
Host * SetEnv TERM=xterm-256color
That’s a neat trick! Didn’t know setting env vars was possible in ssh configs
If you want to use in a terminal emulator features that do not exist in any xterm variant and the remote computer does know only xterm, there is no way to do that without installing data into the terminfo database.
Otherwise, there is no need to install anything, you should just set the environment variable TERM in the remote computer to one of the xterm variants and then modern terminal emulators like kitty or ghostty will still work fine, but of course only as long as you use the xterm-compatible subset of their features.
It's not a VAX that you're physically plugging a terminal into. The remote machine is totally capable of communicating with a newer terminal, it just needs to know how. You're being nice by giving it that information. You can also just install it locally in your home directory (~/.terminfo). (You used to be able to stuff the entire entry into the TERMCAP environment variable and not install anything.)
If the remote machine doesn’t have the right support for your terminal, what do you suggest?
You can install stuff--with tic(1)--inside your user account (you do have one, right?) and be happy that way.
Yea unfortunately eg Ubuntu’s bashrc has a script which will make it drop colors regardless of the presence of ghostty’s terminfo. Its `screen` will also fail, so e.g. it will refuse to upgrade to a new distro release.
Lots of jank due to this custom terminfo.
Every terminfo is custom, to the terminal it applies to. It's just that most entries are 20+ years old and even glacial distros have converged on some version of the database that mostly worked, until the recent resurgence of interest in actually writing new terminal software.
You can also just add this to your SSH config to get the typical functionality working:
I'm still using Wezterm here due to its Windows support, and I like being able to share one configuration my company Windows and my personal Linux laptops.
I've come to like its hyperlink rules to automatically generated clickable links to Reviews/Issues/Requirements/Linter Errors/... so I haven't felt the need to switch yet to have this feature missing.
I'm eying Kitty though.
Same. Windows with WSL at work and personal Linux. Run wezterm on both with shared config. It’s amazing.
Does anyone else always read this as "Ghost Titty"? (Happy Halloween btw)
I have an interesting reason to not upgrade:
I use ghostty as my go-to terminal on my linux devices. I chose it after trying four or so with the way I work. It just works perfectly for me.
But I only really have one use case: 1) Work the way I want it to
I could list my wants as an example, but there is no point because I don't know whether my needs are being met by what they consider a mistake in their design or a feature they provide.
So you can understand my conundrum - am I relying on features and design they consider is broken? If so, my current set up will "break" for me, even if it is a measurable improvement for most other people. I don't know.
I have no reason to "fix" the "working" release for me.
This is meaningful when forced upgrades occur, because the cost of training is never borne by the software provider (looking at you, big 4 or 8 or however many there is now.)
Did you configure emacs to interpret a rapid temperature rise as CTRL..?
https://xkcd.com/1172/
I don't understand complaints like these, the tool is open source, fork it build it yourself and you will never have to update it. You really have the power to maintain your own tools.
My experience with terminals was like this - Alacritty -> Ghostty -> tty7. The last one implements exactly what I had in mind when I used Alacritty and Ghostty. Only it doesn't hype much (the author apparently doesn't strive for that much), maybe that's for the better.
Oohh. I hadn't heard of tty7. I like its goal.
Unfortunately, it seems to be doing something strange - I use vi-mode with nushell and it renders every character I press - even in normal mode.
I might keep an eye on it - hopefully they improve whatever they're doing with local echo.
I should say - I currently use WezTerm for exactly the feature tty7 advertises about session support. Even remote sessions.
Too bad it's still not in Debian.
> These release notes are painstakingly and lovingly hand-crafted by human Ghostty maintainers
Artisan call out work starts. The hipster stance in the AI world.
A bit dismissive, I'd say it's a defensive statement because pretty much everything posted on the internet with a comment system will have an "Is this AI? I can see from some of the pixels and having seen quite some AI in my time" type remark.
ghostty vs xterm.js (the VS Code terminal) - obviously ghostty is going to have better performance, but I just have never hit a performance limit in the VS Code terminal. I don't understand the demand for an ultra-accelerated terminal engine, but it's so popular it must be something i'm missing...
I'm using xterm.js with the canvas/gpu renderer in my app, driving these modern coding agents that seems to use every features in the book of terminals and it's perfectly fine.
The dom renderer is also perfectly fine, just needs a little bit more careful CSS to make it look right with some of the fancy line art.
I do use ghostty and it's alright. It's required for some rich TUI ai seems to be pumping out. Otherwise I prefer tilix and the default gnome terminal, but it might be just because of years of habit.
Here's a recent interview with Ghostty's creator about its philosophy, goals etc. https://alexalejandre.com/interviews/interview-with-mitchell...
I love ghostty and libghostty.
thanks to libghostty, ghostel.el is the nicest terminal for emacs going. Thanks to you & the others behind it.
Is there a plan to have pre compiled binary on Linux? Having to download a zig compiler is a bit annoying...
There's a third party appimage, still on 1.3.1 though: https://github.com/pkgforge-dev/ghostty-appimage
Normally not a fan of appimages, but this group focuses on making higher quality versions that make very few assumptions about the host system and work almost anywhere. While also prioritizing speed, small sizes, and up-to-date dependencies.
you should be able to get it from your system package manager or flatpack. linux is annoying here because it's a GUI app.
The Ghostty bandwagon is pretty loaded up, but iTerm is still where it's at. Recently saw some work on some iTerm work for multiple platforms from someone and it looks like it will work. Pretty excited about iTerm on Linux and Windows.
iTerm on linux would be the dream! I wanted to switch to ghostty for the performance and sane defaults, but it’s just not feature complete with iTerm yet
I miss Ghostty when I am on my Windows machine. Really wish it was available on Windows.
same, hoping for an official build
Updated comment: Ghost is better than Hugo. I am moving my site to Ghost (and because it's drudge work, assigning it to Claude).
I was sleepy and didn't realize in my original comment that Ghostty and Ghost are different.
You're thinking of Ghost not Ghostty
thanks! updated comment. yes, i am still groggy (ADHD early morn)
Are the context menus hardcoded? Ghosttty is the only app on my machine that uses those horrendous rounded context menus, and because I don't use a compositor, they also have a giant black band around them. None of the config file settings seemed relevant, but maybe I missed something?
window.zig: widget.addCssClass("no-border-radius") when no compositor is detected seems like it should be preventing this, but it's clearly not working.
At this point, I'm really looking forward to Rex.
I've been a laggard in switching to Ghostty because I used WezTerm and wrote a plugin to customize it to my liking. I switched to Ghostty just because I got tired of nothing happening in the WezTerm land and wanted to try something different.
Rex will allow me to use my old workflow again.
Same boat here. This makes me think I’ll switch to ghostty soon
How’re you feeling after the change?
Got the Rex beta but haven’t looked at it really. I made a custom Claude code harness that is orchestrated by go CLI Claude wrote for me and that uses herdr for session management. Probably there’ll be something interesting I can do with Rex in the future as an alternative
I have quite enjoyed using the kitty image protocol in interesting ways.
I made a Claude code skill telling it to put a little image in the corner of the console when it does a render to see how something looks. It was quite fun telling it to draw a chicken with 5 SVG D paths and watching it iterate in the terminal.
Kitty is so awesome. I'm writing (well, as much as anyone writes) a MUD that models a decent part of Tokyo at 30-60fps over SSH at reasonable resolution (that's the dream, at least). I'm shocked at how fast I can render a big complex 3d environment, in the terminal.
Do you have a project link or screenshots? That sounds super interesting!
Any source/screenshots?
Great to see regular updates, this is probably the first package I install on any Linux distro.
Fast and clean. I find myself using Linux when I want to focus and study.
Windows is for music creation and certain games.
> Building Ghostty from source is not recommended for most users.
Why is that? It reminds me of the XFree86 times when building from source was some unstable, fancy thing that was severely frowned upon.
Probably something to do with Zig. Zig changes so quickly that if you're not using exactly the compiler that they are using, it's unlikely to work.
That seems…fragile. Is there even much future in Zig? The only other major project that I know of using Zig ditched it.
That is a concern yeah. But I think less of an issue as Mitchell has the Zig team on speed dial.
Here's a delicious meal we prepared for you. We don't recommend you going to the kitchen and trying to prepare it all over again.
..but you can!
Nothing controversial here.
Glad for an update. It’s unfortunately still missing table-stakes features for people who use primarily keyboard driven workflows. I guess I’ll stick with wezterm for another year.
What does it have over WT worth waiting for?
Another WezTerm user here. Keyboard support in WezTerm is amazing
* vim like keybindings to select text
* URL, path, hash (or whatever else you need) selection with shortcut
The same or similar can be done with ghostty + tmux, but I prefer to use less if I can.
My config here: https://github.com/daliusd/cfg/blob/master/.config/wezterm/w...
Judging from kitty benchmark, 1.4 is much faster than previous version 1.3.1. Vivido[0] was the fastest terminal when i measured terminal performance a month ago. Now Ghostty is the fastest. Time to catch up.
[0] https://github.com/vivido-dev/vivido
Escape codes are the new html for browsers now called terminal emulators. What a wonderful time to be alive, but very suspicious also :D
> Escape codes are the new html for browsers now called terminal emulators.
Not really and that isn't a good thing in the long run.
There should not be any more complexity in a terminal emulator that will just lead attackers to craft RCEs exploits to your terminal to steal your secrets on your computer just because "Its cool" and has hundreds of escape codes.
I tried Ghostty for a few months, but found that it had the slowest launch time of all the terminals (NixOS) - we're talking seconds instead of tens of ms. Sadly, it looks like the launch improvements here are for macos.
I've been working around it by setting my keybind to
to instantly open new terminal windows when ghostty is already running in a single instance.I had a similar problem maybe a year back. I've stuck to Foot since. I've got a new laptop now though and might be worth giving Ghostty another spin.
What did you settle on?
I like foot but don't mind waiting a few tens of ms in exchange for kitty's graphics.
I'm on Rio at the moment, pending a wezterm bugfix (but I might just stick to Rio). The launch is perceptually instant on all my machines, and it does support sixels and all that nonsense.
Really happy to see all these updates.
I have a niche use case of wishing for font size support ala kitty and markdown files.
Love Ghostty!
Congrats on the release. I use libghostty-vt in my winui3 session manager and it works really well.
Really enjoy using ghostty but I've switched mostly back to konsole for only one reason: memory usage. I'll reevaluate, after reading this!
It finally fixed the tab bugs in MacOS 27 that had a beta release in June.
The update experience in Ghostty is great. I think it takes under 5 seconds from the moment you click accept update and until the new updated terminal is running.
If I am not mistaken, this is like another iTerm-like app. These tools have access to the innards of your system, like a VPN tool with access to all your connections. How do you trust, or build trust with, tools like these? How do you know whether the actor (s) behind them have malicious intent? Do you always build from an open-source project yourself? Is it a solution or the solution?
I use suckless terminal because the entire terminal is 4888 lines of C (including comments). Builds immediately. Starts immediately. Does everything I need it to do.
Have several running; resident set size between 10MB and 19MB.
https://st.suckless.org/
Start with the person that is instrumental in this - Mitchell Hashimoto - you probably use products built on top of or with his tooling somewhere in your daily life already without knowing it. https://mitchellh.com/
I suspect you're getting down voted on this as it feels like this is a failure to educate yourself on something that feels like it should be relatively easy to do so in less time than it took to type your message.
Wait until it is packaged for your distro. It should be vetted then.
If on Mac/Win, you should be used to trusting notarized apps after a cooldown period.
any idea why people downvoting a legit question? what's wrong with them ?
Reply and then downvote, but silently downvoting ? not a real men, hiding behind their keyboard :)
I've put libghostty in my bespoke IDEs and it's fantastic, thanks so much for all your hard work and vision.
Ghostty was using 2gb of ram the other day - I switched back to iTerm and it's now 200mb.
"My Ford used too much fuel on one of the trips, so I switched to Volkswagen and today, on a another trip, it used much less."
In my experience Ghostty consumed much less RAM but when being used Ghosstty used much more. In similar scenarios/usage.
Libghostty is a masterpiece dude. So easy to embed, nice bindings, and it's so fast.
I tried Ghostty, but went to Kitty in the end.
Been a convert for a while it's so snappy
Im the only one no longer uses terminals apps, not even IDE's, now not even terminals.
Claude/Codex app all the way baby. What a crazy world.
Very excited for this feature
I have replaced Ghostty with Rex from Superlogical, it's great and I really like the iOS app too.
I'm sure mitchellh will check out this comment section at some point - any updates on the move away from Github? I don't really see anything that's changed, but maybe it's behind the scenes. I was pretty excited on your initial post about it but it's been a while.
Sure enough, one minute later he posted a comment lol
Unfortunately he didn't talk about this..
My biggest gripe with Ghostty is that on Mac, window state restoration doesn't remember the previous contents of the terminal, only the working directory. I've been meaning to switch back to iTerm2 over this, but just been lazy. It can be difficult for me to remember what a tab was used for just based on the working directory.
Kitty can do that now, though.
Hmm I wss checking for updates last night actually. I really hope they dont start adding llm junk to ghostty. I really like it, but mitchel sounded like he got bit by the llm bug a few months back.
Its honestly perfect as it is, just nerd performance tweaks imo.
Truly odd to see this comment. For me, mitchellh defines the moderate position on agents in coding, I mean that seriously: not occupies it, defines it. I’ve raised this point in discussions and others get what I mean without explanation. He’s better known for a mitigation to LLM downsides (vouch) than for making conspicuous use of them, and insists on human-only prose in issues, PRs and ‘real’ documentation (which I firmly agree with btw).
He also has a blog post and some tweets about how they can find and fix difficult bugs, and otherwise are capable of solving hard problems now. Well, they can.
Is that the LLM bug to you?
https://mitchellh.com/writing/superlogical
Because this company, and the superlogical idea intially emphasized building the terminal multiplexer for the agentic age.
Now if I could only upgrade it without powering down my current Ghostty
tmux, baby!
I'm a GNU screen guy but I generally don't run it locally as that's.. what you have tabs for :)
Or Rex ;)
damn, i don’t check this stuff for a month and boom now i must try Rex!
i signed up for the mailing list, do you just wait a bit?
happy to hear your thoughts while i wiggle in excitement!
Wrote a VT parser once, bracketed paste edge cases ate a whole week. Respect.
Does anyone know how to use ghostty in VS Code?
I think if you had Claude Fable build a lightweight terminal like Ghostty, you'd get a good one.
I doubt that very much.
An LLM may be fine to implement quickly an application that more or less works, but I have not seen any evidence that any of them is able to write well optimized code, whenever the application is not just a duplicate of something older.
Ghosstty and a few other newer terminal emulators are not only lightweight, but they also implement very fast GPU rendering, which is one of their important advantages.
So not only their set of features matters, but also the achieved performance.
Of course, one could use an LLM to write a very fast terminal emulator, but for that a competent programmer must be included in the feedback loop, which would require many iterations and running benchmarks and emulation conformity tests. It cannot be done by vibe coding with a prompt like "write a lightweight terminal emulator".
I've reimplemented ghostty in Rust and it performed on par with ghostty.
I've also given various models access to the tools necessary to measure performance and instructions to make things faster and they do pretty well. Hill climbing on a validatable measure is reasonably easy these days.
My direct experience here directly contradicts pretty much everything you've said can't be done. I.e. the human out of the loop stuff.
Here's one such project: https://github.com/Dicklesworthstone/frankenterm
However, it is more focused on multiplexing.