Ghostty 1.4
ghostty.org
ghostty.org
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!
That's really cool, but I'm drawing a blank; what's it used for? Embedded terminal something?
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
Just took our TinyBubbles framework (TinyGo + BubbleTea) and added TinyGhostty [1]. We had all the parts in place.
The web demos use Booba [2] and our ghostty-web fork, so that's libghostty embedding another libghostty. The source cells are composited into our TinyHAL device abstraction. The UX is presented using "Booba Actions" which abuses OSC 7501.
This describes the differences between TinyGhostty and go-libghostty [3]. I've run other demos on embedded devices, but not this one yet. The fonts could use some love.
[1] https://nimbleterminal.github.io/TinyBubbles/?demo=tinyghost...
[2] https://github.com/NimbleMarkets/go-booba
[3] https://github.com/NimbleTerminal/TinyBubbles/tree/main/tiny...
it is all open source: https://github.com/hotaisle/hotaisle-website
Wanted to add too that I can't wait for xterm to eventually support libghostty, you've been super supportive providing feedback!
But I can't do this any longer. I'm tired, boss.
Erm, this really depends on the human I think.
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.
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).
Turns out they were quoting Rumi from K Pop Demon Hunters and I indeed am uncultured.
The one I am mentioning is جلال الدین محمد بلخی رومی So the sufi saint.
Although not necessarily advertised as such, I've been successfully using alacritty in several projects injecting terminals into things both serious and silly.
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)
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!
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.
But if you run nix you could give it a whirl: https://github.com/KritR/ghostty-kms
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.
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 worldZig has its own compiler backend. With limited arch support of course. Only used in debug modes for now.
I think the most interesting part is they rely on WASM for bootstrapping so all you need to make to bootstrap Zig anywhere is a WASM interpreter (if I understand correctly).
* With some UB herbs and spices
Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.
For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.
PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.
That’s implying a lot more than I think is the case for Zig.
Zig itself is a very lean and independent executable. It’s just one binary. Statically linked on Linux I believe. It’s even moving toward removing LLVM dependence.
I don’t know of any other language that aims to be as portable as Zig, including C itself. Of course, not all of those goals have been realised yet, but at this stage I don’t think there’s much preventing portability from Zig’s part itself, other than more architectures supported in its own compiler backend. And I suppose a 1.0 release would make it easier to get the compiler more widely distributed.
It's a pleasure reading your posts.
I do not know if you read my initial commment, but MacOS Terminal (native app) has this feature. And it is not a terminal multiplexer like tmux or what you proposed.
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
There is no reason why programs input/output can't be schema'ed, consumed and piped in a type-safe manner. And why there can't be a better standard than bash for simple scripts.
But it is really hard to pull this kind of thing off unless you redesign most of the common tools by scratch and do so through a committee and somehow push it down people's throat through strict platform control.
No need to push it to people. Do it for yourself and create your community around it.
Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.
Turns out that the warts are the incorporation of the lessons learned. For this reason, just before Wayland fulfills its destiny and becomes an immaculate replacement for X11, a new generation of developers will determine Wayland's codebase is too complex to comprehend and must be rewritten from scratch.
When you say you've proven, are you hinting at use of formal verification?
Any interest in moving console typography past the 80's, since computers are fast now?
Here's a screenshot: https://files.catbox.moe/932rsg.png
If that sounds interesting I might be willing to publish it, but I'll warn you now that it is vibe-coded. I've been iterating on it for a couple months now though and I think we've worked out pretty much all the kinks.
(a couple of us working on packaging libghostty and ghostty proper to for Guix at the moment )
https://ghostty.org/docs/config/keybind/reference#toggle_qui...
Last time I checked it didn't work on Linux (or I couldn't make it work on my setup, I don't remember). It seems it still has some limitations but better than before.
keybind = global:cmd+ctrl+alt+shift+t=toggle_visibility
overall I have had better experience using `toggle_visibility` to show/hide Ghostty for hotkey style window.And right afterwards you write that not only it is the case, but the change is very recent !
[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
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.For me, the major pain was font rendering. I could not find a portable configuration that would work with any screen. And even worse, for some pixel densities, whatever configuration I tried, the result was awful. In some cases, I vaguely remember there was a legacy mode that made text legible, but it had its own problems.
As an aside, I love ghostty and I think it's the most responsive terminal emulator around. But kitty was what got me off Terminal.app and I think it's not given enough love around here.
I added Tmux control mode (a pretty extensive feature) https://github.com/tmux/tmux/wiki/Control-Mode to Ghostty: https://github.com/eliasfloreteng/ghostty-tmux and I use that version every day
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.
Having having an industry player like hashimoto's superlogical driving terminal features is the extreme version of that
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.
A lot of other terminal emulators can expose similar reusable things (alacritty comes to mind) but libghostty is the most well supported one
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.
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.
- 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
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.
There was also some pretty noticeable differences in character rendering between the two with identical-as-I-could-make-them font settings.
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.
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.
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've tested a number of Terminal Emulators on macOS and Ghostty's rendering is always superior.
You should give 1.4 a try.
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 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.
Also the konsole context menu and default toolbar are a mess.
Ghostty is getting there though, and today is a milestone, not complaining too loudly.
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.
Surely you understand Konsole is not already there for most people?
> 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.
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.
That is, in my opinion, the correct default.
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.
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.
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.
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.
If people want it enabled, they can enable it. It shouldn’t be the default.
Someone? Almost certainly
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.
So far I can only think of 1: term vulnerabilities due to ANSI escape sequence parser bugs. And that’s exactly the reason I’m suggesting OSC8 should be off by default.
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.
The latter seems always to be about aesthetics, not about UX.
This sounds like a deliberate choice from Apple TBH because they, well, like their UIs and don't want to promote TUIs necessarily :)
> By default, Konsole disables OSC8 link support.
Is this for security reasons? I am sure the Konsole has a reason for it.Cool! How fun, I'm a big fan of your work and will enjoy learning from this project too. (:
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.
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 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).
I’m strongly skeptical of this as pty are character devices and buffered. Programs and terminal are very loosely connected.
There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.
Why? If you use something like tee(1), you can get the full log in a file and then filter line according to what you want.
> Compiling any big software project produces far more text output than can be stored in any pty buffers.
The reason of my skepticism is that, according to your statement, reading a source file, then writing the compiled object file is way faster than a few printf through a kernel object in memory. Even for the terminal consuming the characters, parsing, and displaying the lines should not be a computation hog for most terminals
Xterm failed me :( Tabby just works.
Namely it is wayland only, cpu rendered, and doesn't have any window decorations
I've just reverted back to using that as it's faster to load and has all the features I need.
The acceleration is the primary point.
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.
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.
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.
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.
Actually I think xterm was even more performant, but the eye sore wasn't worth it for me.
If you're genuinely not trying to be dismissive and just have a sincere question you want to have an answer to then I _strongly_ implore you to be more aware of and careful about how you express yourself.
Because as your first sentence is worded virtually all readers will assume you are hostile and not asking in good faith.
Inspect + build yourself
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.
Mitchell is a beautiful exception and it makes me happy.
I've always wondered what would happen if more people got a lot of money through more communal-oriented ways.
If it was always in a standard format, it wouldn't be a problem. Something like dconf, without the poor design.
Having to search for some obscure configuration names and options is simply getting in the way.
For that reason I stayed away from Zed for ages - it is a fine editor but tweaking it options without even rudementary settings GUI was just super-meh.
I do hope that Ghostty will go the same route and they will add something that would help manage the simple config options (backed by the config file) without having to deal with purely-textual form)
Maybe I framed it wrongly. Though general vibe in every Ghostty posting is "why are you still not using it?!" which is weird…
> It's a technically excellent terminal built with an incredibly rigorous and well thought out guiding philosophy and a remarkable amount of passion.
I get that but... while it may be excellent on technical level at the end of the day it's a tool and if it's lacking (and for me it is) then it doesn't matter how excellent it is?
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]
Uhm... what prompts? ;) I do have auto-update and it does it in the background -- I haven't seen any prompt in ages.
Alternatively you can use brew/Latest.app to handle updates when it's convenient for you?
I quit using iTerm 2 because of the AI features. Ew.
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.
But I switched due some iTerm2 bugs and performance reasons (I'm usually running up to ~100 terminal panes, split across 4-5 windows and up to 9 tabs per window) and it was much easier than I expected. I got used to my hotkeys bringing up full-screen quick terminals instead of half screen ones and that's actually usually what I want anyway, and iterm just feels more hackable in general; my agents are able to help get input to and from the various panes quite easily, and I haven't had a single bug or crash so far.
Yeah... I could maybe see that but for me at best I have a dozens of terminal panes and I haven't seen any slowdown in my usecase :)
Host * SetEnv TERM=xterm-256color
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.
Host ...
SetEnv TERM=xterm-256colorLots of jank due to this custom terminfo.
iterm2 is fast, reliable, and second nature. i don't have to edit settings every day.
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
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.
Do you have specific examples of usability issues?
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.
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...
Would be great if we could opt out a few pre-determined key combinations from this system, but I guess that's never happening.
Thanks so much for maintaining Ghostty tabbed quick-terminal by the way, you're a legend <3
Or, just please finally enable tabs in the quick window, people are shouting about this for years, making forks, ready made PRs … This functionality is a table stakes in 2026.
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.
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.
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.)
Can someone comment on ghostty vs wezterm? both are very popular, wezterm is much more configurable due to lua scripting, I suspect performance is going to be identical and not measurable by humans.
I always end up back at "st" though. It is fast enough for my purposes and does just about exactly what I want and not more. Reading about Ghostty 1.4's D-bus activated window creation I was wondering about the actual measurements of the improvements given the added complexity
A footnote mentions that the creation time of a new emulator window goes from about 200ms to 20ms. That made me wonder why the regular startup time is so slow ...
Turns out that at least on my setup ("st" on X11) you can get quite close even without the added complexity.
$ time st -e 'exit'
real 0m0.021s
user 0m0.011s
sys 0m0.005sArtisan call out work starts. The hipster stance in the AI world.
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.
Why is that? It reminds me of the XFree86 times when building from source was some unstable, fancy thing that was severely frowned upon.
Does it mean that it's only viable to use the zig programming language if you can have "their team" on speed dial?
..but you can!
Nothing controversial here.
thanks to libghostty, ghostel.el is the nicest terminal for emacs going. Thanks to you & the others behind it.
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'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.
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
That says a lot because I really liked WezTerm (I was sponsoring Wez on github because of it) and I still do. But, the development stopped to a crawl, Wez has other priorities (obviously) and it was time for me to find an alternative.
Ghostty is fine, but I want a scripting language for my terminal - I don't need much, but those few little things mean a lot to me. Based on the Rex docs, I will be able to make it work for me the way I used WezTerm before the switch.
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.
https://github.com/NimbleMarkets/ds4go-apps#svgpad
We have a bunch of interactive Kitty Graphics demos, which run embedded in browser or from terminal. This weekend I was working on watercraft simulation:
Fast and clean. I find myself using Linux when I want to focus and study.
Windows is for music creation and certain games.
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.
* 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...
If wezterm adopted libghostty I would have little reason to switch.
I was sleepy and didn't realize in my original comment that Ghostty and Ghost are different.
I like foot but don't mind waiting a few tens of ms in exchange for kitty's graphics.
gdbus call --session --dest com.mitchellh.ghostty --object-path /com/mitchellh/ghostty --method org.gtk.Application.Activate '{}'
to instantly open new terminal windows when ghostty is already running in a single instance.To some extent on Linux, too, but not under GNOME, apparently: https://ghostty.org/docs/install/release-notes/1-2-0#gtk:-qu...
I have a niche use case of wishing for font size support ala kitty and markdown files.
If on Mac/Win, you should be used to trusting notarized apps after a cooldown period.
Reply and then downvote, but silently downvoting ? not a real men, hiding behind their keyboard :)
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.
People are assuming the wrong thing I guess. We should always assume for the positive intent.
Have several running; resident set size between 10MB and 19MB.
Claude/Codex app all the way baby. What a crazy world.
Its honestly perfect as it is, just nerd performance tweaks imo.
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?
Because this company, and the superlogical idea intially emphasized building the terminal multiplexer for the agentic age.
i signed up for the mailing list, do you just wait a bit?
happy to hear your thoughts while i wiggle in excitement!
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 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.
However, it is more focused on multiplexing.