I'm the original creator of Ghostty. It's been a few years now! I don't know why this is on the front page of HN again but let me give some meaningful updates across the board.
First, libghostty is _way more exciting_ nowadays. It is already backing more than a dozen terminal projects that are free and commercial: https://github.com/Uzaaft/awesome-libghostty I think this is the real future of Ghostty and I've said this since my first public talk on Ghostty in 2023: the real goal is a diverse ecosystem of terminal emulators that aim to solve specific terminal usage but all based on a shared, stable, feature-rich, high performant core. It's happening! More details what libghostty is here: https://mitchellh.com/writing/libghostty-is-coming
I suspect by the middle of 2027, the number of people using Ghostty via libghostty will dwarf the number of users that actually use the Ghostty GUI. This is a win on all sides, because more libghostty usage leads to more stable Ghostty GUI too (since Ghostty itself is... of course... a libghostty consumer). We've already had many bugs fixed sourced by libghostty embedders.
On the GUI front Ghostty the apps are still getting lots of new features and are highly used. Ghostty the macOS app gets around one million downloads per week (I have no data on Linux because I don't produce builds). I'm sure a lot of that is automated but it's still a big number. I have no telemetry in Ghostty to give more detailed notes. I have some data from big 3rd party TUI apps with telemetry that show Ghostty as their biggest user base but that is skewed towards people consuming newer TUIs tend to use newer terminals. The point is: lots of people use it, its proven in the real world, and we're continuing to improve it big time.
Ghostty 1.3 is around the corner, literally a week or two away, and will bring some critically important features like search (cmd+f), scrollbars, and dozens more. In addition to GUI features it ships some big improvements to VT functionality, as always.
Organizationally, Ghostty is now backed by a non-profit organization: https://mitchellh.com/writing/ghostty-non-profit And just this past week we signed our first 4 contributor contracts to pay contributors real money! Our finances are all completely public and transparent online. This is to show the commitment I have to making Ghostty non-commercial and non-reliant on me (the second part over time).
That's a 10,000 foot overview of what's going on. Exciting times in Ghostty land. :) Happy to answer any big questions.
What has it been like witnessing terminal emulators make such a huge comeback with the advent of Claude Code et. all? I remember comments here in the early days of Ghostty along the lines of "Why is he working on a terminal emulator? We need people working on future problems, not the past!" Pretty funny considering I regularly hear people say they are in the terminal more than the browser now. Crazy times!
If you told me 3 years ago that terminal usage would _increase_ I would've laughed. Beyond that, I'm now having regular conversations with the frontier agentic coding companies (since they're far and away the largest terminal users at the moment) and if you had told me 2 years ago that that would be happening because of a terminal, I would've laughed even harder.
Wait, really? So I’ve used the terminal for everything for decades, and now, because of vibe coding, all The Kids have joined me? I don’t even know how to feel about that. Better terminals are nice though.
/* Claude Code is the strongest case of the return to the mainframe: a closed, bespoke, paid service that nothing locally run compares to. Terminals are just a natural part of the mainframe world! */
What's it been like managing a fairly large project with Zig? I know you've spoken highly of the language in the past, but recently it seems like Zig has been through some substantial changes that would be relevant to a terminal emulator. I'm curious how painful the churn has been for project maintainers.
It's been extremely good. I should really blog about it in more detail because I do get asked this question regularly. It's been very good.
The large language changes are a burden, but it's something I knew going into it. And so far in every case, it's been well worth it. For example, 0.15 introduced the std.Io.Writer overhaul, but I really love the new API. I haven't started the std.Io change yet for 0.16. We'll see. And honestly, LLMs make this all way less painful... even though they're not trained on it, agents are able to run builds, reference docs, and work their way through the upgrade with huge success.
I thought that finding contributors would be an issue, but it hasn't at all. There's a lot of people out there eager to use Zig, the language isn't hard to learn (as long as you're already familiar with systems concepts), etc. It has been good.
I'll think about more to say if I write about this more but overall, I'm very happy with the language, the community, and the leadership. All good.
My brother has built a game using python on the CLI and I've been trying to find a way to package it. Your project seems very promising for my use case.
Project mentions Windows compiles but isn't tested. Do you have a gut check on what issues there might be?
Coincidentally I was just listening to your interview with The Pragmatic Engineer [1] this morning. Loved hearing the stories of early days at HashiCorp, taking it public, and the near-miss with VMware.
It also got me wondering how things would be different if you haven't crossed paths with the guy who unplugged your mouse :) It's fascinating how life is full of these small yet defining moments. We don't always appreciate them right away, but beautiful to look back.
Thanks for Ghostty! It has been my daily terminal driver for the past year.
I was also just recommended this interview on youtube. honestly it makes sense if the algo decided it was the right time to recommend this video and resultantly this post is making it's way to front page of HN
Thanks for all the work you do! I had used terminal just a few dozen times before November — and now i am in terminal more than any app (even more than the web browser).
It’s common for me to have 15-25 different terminal windows open for using Claude code. I shifted to Ghostty because I was looking for more features.
Unfortunately, none of the features I wanted are available anywhere (though I’ve come to appreciate Ghostty anyway). Here’s what I had wanted:
1. Basic text editing features (ie click to place cursor in the text input field; highlight to delete)
2. Change colors or fonts mid session (to make it easier to find particular windows)
3. Window management and search (eg, a way to find my windows when I lose them and to otherwise control them)
Apparently, it is really hard to develop features like these for terminal emulators. I’d love to understand why…
The next release includes a way to use a command palette to search for and jump between surfaces (windows, panes), which sounds like it partially addresses your third point. I had a small hand in it, by building the initial UI for the Linux version.
IMO this isn’t the job of the emulator. You can do this all in `tmux` for example.
As for editing text, ghostty+tmux most definitely supports editing text with the mouse (even an in terminal right click menu!) although sounds like your intended use of select to delete isn’t common so you’ll need to do some customizations.
Now that Ghostty is part of a real org, is there any way people can sponsor specific features/bugfixes? I've been waiting for drag/drop to be working on KDE before I make the switch, and I'd be happy to pay for a fix.
> the real goal is a diverse ecosystem of terminal emulators that aim to solve specific terminal usage but all based on a shared, stable, feature-rich, high performant core. It's happening!
I recall the package manager war of Haskell between "stack" and "cabal-install":
Users would have strong opinion depending on their background.
But the developers eventually made both projects use the same libraries.
Both tools allow for ghcup to manage the compiler, so there's no conflict there.
The difference is eventually just a frontend experience, and all the heavy lifting and synergy is achieved behind the scenes.
I would not have believed the same is possible for terminals, even cross-platform, so thank you for having this vision.
The real goal isn't for Alacrity or Kitty or WezTerm or any other terminal to use libghostty. I think over the long term, terminal emulator user bases dwindle down to niche (but important) use cases.
The real goal is for higher-level tooling (GUI or browser) that utilizes terminal-like programs to have something like libghostty to reach for. I think this represents the much, much larger ecosystem out there that likely touches many more people. For example, Neovim's terminal mode, terminal multiplexers, PaaS build systems, agentic tooling, etc. You're seeing this emerge in force already with the awesome-libghostty repo.
libghostty would still be useful for traditional terminal emulators to replatform on, and for example xterm.js is seriously looking into it (and I'm happy to help and even offered their maintainer a maintainer spot on libghostty). But, they're not the goal. And if fragile egos hold people back, it's really not my problem, it's theirs.
As an outsider to the fascinating world of terminal emulators... can you explain why this might be? Rather, what about `libghostty` would be off-putting vs `libtermengine`?
Just that it's a specific "product"-y sounding name? Would you also be concerned about "libwayland" vs "libcompositor"? Genuinely curious: this seems like an insightful question, I just don't follow the reasoning.
Many thanks for everything. Without Ghostty I wouldn't have been able to create https://github.com/rcarmo/webterm and have a decent browser-based terminal that works the way I expect it to.
Having incorporated libghostty into my current web-based project, I can't say enough thanks. I've lived in the terminal since 2003, resisting IDEs, VSCode, everything because I'm a die hard Vim + tmux guy. Vibe coding coming back to the terminal, and being able to use libghostty to facilitate that is a serious vindication of my steadfast resistance to move away from the terminal.
I'm sure you feel the same watching Ghostty become what it has. Big thank you.
mitchellh: What is the current thinking WRT adding client/server functionality (like built-in tmux+mosh)? I recall you talking about it on the Changelog podcast, and that would be a killer feature for me; I really make a lot of use of the wezterm equivalent, it's so nice having first-class UI windows rather than tmux's faking of it.
You're one of the forefront experts in terminal protocol parsing. Do you have opinions on "interceptor" applications like tmux or mosh, for example? These applications technically need to do extra upfront work (especially mosh as it transforms the entire protocol) and it's not a transparent "I treat vt100 as a black box, I put bytes in, I get well structured, standardized events out". Does libghostty-vt support that currently, does it intend to support these kinds of protocols in the feature, or is this kind of thing outside the scope of the project?
Random advice question. My brother taught himself to program and has been making a terminal-based game. What started out small has turned into a highly polished game with ascii art, sound, you name it.
I’ve been trying to figure out how I could actually help him distribute it and I keep coming back to the best option being to wrap his programs terminal output into a host process that can emulate and render it. It seems that the lib Ghostty might be perfect for the former, but not quite yet on the latter?
I don't have specific references for you, but perhaps you could look into how old-school roguelikes packaged their software for distribution. Particularly ones that made the jump to Steam or Itch?
I started using it a few days ago and then I need to find something in the terminal. But....there is no find! Why? Can you guys add it? This is such a basic and critical feature that I may have to just go back to...just about anything else.
Do you know of any Qt based libghostty front-ends? Also, hows zig for a relatively complex project like this? I like zig in theory but have always been worried about using it since it's still pretty early days
I literally discovered Ghostty yesterday when googling "best terminal macos" and surfaced a ~year-old reddit thread recommending it [0]. Just needed something other than Terminal so I could Cmd-Tab between distinct command-line work (e.g. claude code and ipython tabs). Was nice to find something that just worked
Hey Mitchell, thanks for ghostty (happy user here for a month or two). Is there anywhere I can look to see the status of the next planned release?
I've been waiting for the vim feature to hit stable, and have just been checking to see if there's a new release every so often, but I couldn't find a discussion or anything to see when it was planned.
I use Ghostty as my main TUI at work and absolutely love it. Most of my day lives in terminals, and Ghostty just feels fast, clean, and out of the way in the best possible sense.
I was a long-time Kitty user, but switching to Ghostty has been a big upgrade for my workflow. Hard to go back now. Thank you
Excited to see the further development of libghostty! It is an exciting project in this new world of being able to develop your own agentic development environments rather effortlessly. These things are possible because of projects like yours. Thank you!
Thanks for creating Ghostty! Is there a chance to have shorter release cycles? I switched to nightly because of the mem bug and search, but ideally would like to be on a more stable channel.
I just wanted to say "thank you". I switched to Ghostty over a year ago and it's been working out great. It's now my default terminal. My favorite features are responsiveness and ease of splitting panes.
Hi Mitchell, thanks for creating Ghostty. Been part of my workflow ever since I found it. Just a small question, when do you see Ghostty can fully replicate iTerm2 popular features like output copy/selection?
Is there any chance of a stable release that fixes the memory leak issue? I know I could run nightly but for something I spend all day every day using I'd much rather run a stable version.
> On Linux, the quick terminal is only supported on Wayland and not X11, and only on Wayland compositors that support the wlr-layer-shell-v1 protocol. In practice, this means that only GNOME users would not be able to use this feature.
Recently tried multiple terminals because I am gradually migrating off of Macs and I liked Ghostty but the lack of searching the scrollback has turned me away from it. Opening another editor to do the same I tried but didn't like.
WezTerm has everything I need and is closest to iTerm2, minus being able to quit it and have it restore all windows and tabs on restart -- but oh well, it's not an important enough feature. It also renders my prompt perfectly; no small pixel divergences like all other terminals have.
Kitty I don't remember why I rejected.
Alacritty I like but the lack of tabs is not acceptable for the moment... and before you ask: I hate tmux. So much more key presses to achieve basic functionality, it boggles my mind why people love it. But, to each their own obviously.
It's also likely I'll settle for some Linux-exclusive terminal but as I'm not yet possessing a Linux workstation (just a laptop) I haven't put the requisite time to do this research.
Maybe worth another look at then? I'm far from a Kitty power user, but it does pretty much everything else I want it to, including working as a quake-style terminal[0]. And you can extend it with kittens[1] if you so desire. Also, the next release should presumably include smooth scrolling[2] which I'm quite looking forward to.
Maybe more than any one feature though, I appreciate the hard work that Kovid (the creator of Kitty) has done to tastefully add new VT standards and try to make terminals as useful as they can be in the 21st century.
Kitty is the best one. It has several features which have proven so useful I wasn't able to stay on anything else for more than a couple of hours (including the one this topic is about).
Ctrl+Shift+G wraps the output of the previous command into a pager (say, less). You often only know you needed a pager after that output is printed.
Ctrl+Shift+E highlights all links on the current screen and assigns short alphanumeric codes to them, so you can open links without using the mouse. For example, `Ctrl+Shift+E 1` opens the first link, `.. 2` the second one, etc.
Ctrl+Shift+U opens symbol search where you can find & insert symbols using their unicode names. Emoji, TUI blocks, rare accented characters you need once in a blue moon, CJK ideographs, whatever.
Kitty is great, but its author has very strong opinions, strongly held; this keeps a number of popular requests summarily rejected. In particular, there is no way to color plain bold text, which is possible in basically any other emulator. This is a deal-breaker for me personally, it makes reading e.g. man pages unnecessarily hard.
I'm not the GP, but I do remember why I rejected Kitty when I tried several terminal emulators last years: it broke quite a few of my workflows.
For instance, in vim the F3 key was broken[^1]. It was very surprising and weird, and a portable workaround required some arcane vim configuration.
Another important pain point was that the font rendering was different in Kitty to any other app, and very dependent on the screen DPI. IIRC, for a DPI around 100, I had to switch to "legacy rendering" because the default rendering was barely readable.
I also remember issues with SSH. And Kitty crashed at least once. And I wasn't a fan of Kitty's mix of C and Python. After a week or two of usage, my Kitty config file was big, with an extra hundred lines of Python for the tabbar. Despite some nice features (like the shortcut to put the output of the last command into a file), I got uneasy with all this mess. I tried Ghostty, which was as good as Kitty with much less oddities.
I wouldn't say I love tmux, but I have a configuration file that I put on every computer I use regularly that is very comfortable for me. I basically live in the terminal across many different machines, and having the same interface for managing panes and tabs even when using ssh is invaluable.
I also use vim (well neovim) as my primary editor, and have set up tmux to integrate well with it, so that might contribute to my appreciation and continued usage of it.
If you spend any amount of time on remote machines with unreliable connections, local tmux is insta-reject because tmux inside tmux is very inconvenient. As with GP, it's also why I don't consider terminal emulators without tabs at all.
Yep, I've been using tmux for almost 10 years. Its config has followed me across every terminal I've used in Windows with WSL 2, macOS (work laptop) and native Linux. It's a nice abstraction over getting split panes, windows (tabs), sessions, search, scroll back, consistent key binds and the overall theme to work the same across environments.
What proper window manager shows tab group list at the top of the current app window and allows shortcuts/mouse to reorder the list and also allows moving a tab outside of this list to another tab group?
Scrollback does exist on Ghostty! But you need to switch to “tip”. This can be done in the config file.
The tip build is very stable and has many bugs fixed (like various memory leaks).
there's scrollback search in the nightly build if that's an option for you (I've been using it a ton for a few months and haven't seen any bugs so far):
I haven't seen anyone else mention Terminology yet. It uses an unconventional GUI framework (Enlightenment / EFL), but that aside, it's fast and has more or less all of the features you'd expect of a terminal:
Back in 2018 I thought it felt kind of sluggish and consumed quite a bit of resources, but looked pretty. Have they improved on performance since then?
You can search scroll back on Ghostty nightly. I switched straight from iTerm2 (after 20 years of iTerm), but _do_ remember the reason I rejected Kitty: it has a ton of Python in it, which is usually indicative of software which is going to be a pain in the ass.
I like tmux because it does more than tabs in an emulator. I can detach from a session on a remote host to leave a process running after I disconnect, or to pick the session back up on another PC.
I do use tabs rather than repeatedly switching tmux sessions, but I do end up running tmux for splitting the GUI into side by side layouts.
Detaching is working just fine with `screen` as well.
I like the idea of tmux but as another poster suggested, I prefer to just get better at my
window manager to achieve similar results. tmux requires way too many key presses for me.
> Alacritty I like but the lack of tabs is not acceptable for the moment... and before you ask: I hate tmux.
Surprised none of the other commenters have mentioned zellij. I work across windows (WSL) and linux so really like having the same set up for both, which means no Ghostty/Kitty since they don't support windows.
Zellij is a lot smoother and nicer looking out the box, and its key shortcuts are pretty intuitive. There's a lit of advantages to not having an extra layer, but zellij + alacritty is definitely worth having in your list of options!
Very glad for that--it's what made me stop my evaluation the first time around. I looked for the feature in issues and just saw #9821 about memory use of the buffer which could be an issue if configuring very large scrollback as I do.
BTW is there feature parity between macOS and Linux, e.g. scrollback buffer searching on Linux?
I built a Windows terminal emulator (TerminalNexus) and scrollback search was one of the first things I prioritized. Ctrl+F opens a search dialog with regex and case sensitivity, and the buffer size is configurable per shell profile. No tmux needed.
Personally kitty is the only one I keep coming back too. Mostly because it's very customisable, fast, lean, ligatures, separate font for italics, great macro support, and supports automatic tiling panes.
> Alacritty I like but the lack of tabs is not acceptable for the moment... and before you ask: I hate tmux. So much more key presses to achieve basic functionality, it boggles my mind why people love it. But, to each their own obviously.
Tabs usually mean mouse+click to switch which takes way more effort that a simple alt+number or similar keybinding used to switch "tabs" in tmux. I'd guess that some terminal emulator tabs allow keybindings to switch tabs as well but, modelling OP, I'm focusing on the expected default experience.
No, zero mouse usage, you can both address each tab by number and just moving between them. I wouldn't have any terminal emulator without the latter feature at least, and all I've tried support it.
You can turn on a feature documented as allowing the terminal to be controlled by escape sequences, but then output of programs can control the terminal! Whoop-de-do.
I love Ghostty, especially the UI is so much nicer than Kitty. However, for some reason ghostty sometimes has severe issues with dealing with SSH connections. The terminal is like broken and wrongly displayed and you can't properly type something. Therefore, I still use Kitty, especially for SSH connections. I don't know what `kitten ssh` does, but it makes my terminal work with SSH.
This is what kills it for me. Half the time I'm using a terminal I'm sshing and the fact that I need to copy over term-info on virtually every machine keeps me from using it more often. Even copying term-info doesn't always fix it. From what I've read it's not entirely ghostty's fault but as a user it's frustrating.
Same. On the tip of main, at least, I can open the command palette and choose reset to bring it back to life. I set a keybinding for reset to skip the command palette.
He probably refers to the fact that Ghostty aims to use the native window decorations etc.. So for example on Ubuntu it uses gtk, on mac the native macOS tab bar etc. Same goes for the scrollbar and search window.
Big one are the tabs. Kitty has tabs, but rendered in the text rows, so it's missing features that the native OS tabs provide (drag and drop, easy to move around and split into windows...)
The fetishization of tools is one of the things that mark a dilettante mindset.
You see it on all hobbies, e.g. when the someone sees a photograph and their first question is about what camera and optics were used. No question about composition, light, the moment, creativity... they only care for the tools.
The technique and knowledge is the important thing, not the tools. They forget the good practitioner can do a great photo with a $200 phone than they with the best Canon DSLR.
I have seen this in all hobbies I have practiced, be it musical instruments, kolinsky brushes on miniature painting, montain bikers, running apparell...
As I'm getting older I care less about editors, terminals, Linux distros... and after seeing what can be done with agentic coding tools less so.
I have no idea why I am responding to someone who flippantly uses a phrase like "dilittante mindset", but here we go
there is definitely a tendency for noobs and amateurs in any hobby or industry to obsess over expensive gear and things that don't matter (I love the term "buyhard" for it). you're out of your mind if you think the professionals in literally any industry do not discuss the specific technical tradeoffs of tools they are using among themselves.
When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine.
I don't feel like this is a fair argument because different tools help different workflows. Since there is always a continuous growth of new people learning new things, it would make sense that tools change over time. Especially in a realm that is digital, not physical.
FWIW once I found my workflow (vim + tmux) I stopped caring so much about chasing "new" tools. Now have the luxury to wait 3-5 years and see what's worth adopting, most of it isn't only because I already found a workflow that works for me; but if you're new or still finding what works best, you'll always be experimenting.
Yes, and one of my favorite anecdotes like this: at one of the greatest jazz concert ever recorded, Charlie Parker played a cheap plastic saxophone because he hadn't brought his own.
It is cringe to buy niche gear and learn obscure in-group terminology because you are trying to short-cut through enjoying the hobby itself directly to enjoying the status and acceptance that non-hobbyists enjoy.
But "fake it until you make it" is part of life too and everyone wants to belong and to be taken seriously. You can't always just "do the hobby for fun" if you want to be social since anxious intermediates whose own output is still crap will gate-keep.
If you can, find hobbies that bring you joy and do them alone, free from the influence of too much right and wrong, at least in the first stages.
In the context of terminal emulators, idk, do something like learn AWK purely for personal enjoyment. You may not have the flashiest dotfiles or color schemes or whatever, but you'll be able to do arcane stuff in the terminal that will give you confidence you belong and others will be amazed by.
This is a very weird take. For people who spend their entire day in the terminal, having the right terminal is incredibly important. Like saying track athletes shouldn't spend money on running shoes if they own a pair of slippers.
I mean, it's all about what works for you, right? I use Cursor's built in emulator and Hyper.sh just because I like Cmd T to work in my terminal. But my workflow is a lot different from a lot people's. Hence, I'm not sure why there's so much debate about people's workflows in this thread. Lots of "you should care" or "you shouldn't care" about your terminal.
This isn't directed at you, of course. Just a weird observation where people are prescribing their workflows to others and telling them what they should or shouldn't care about when the only thing they know about their workflow is that they use a terminal at least once a day.
Can relate well. In my early days I used to jump around linux distros and editors and terminals too, but with time as I have converged down to actually working a tech job.. Windows 10 LTSC and VSCode (with its inbuilt terminal) have become my staples.
For me, using Linux (mostly - occasionally Haiku or some sort of *BSD) then it's VSCode if I need to do it all day, and Vim if I need to do it right now.
I wish I could get out of the habit of opening Vim in VSCode's terminal window but sometimes I'm tweaking something that's "not part of this thing" and it kind of makes sense that way.
This is not about it being a hobby, ghostty is the sanest terminal emulator currently available for MacOS where you can just install and start using it. Customising your terminal doesn't need to be your hobby anymore.
Some people fetishize tool curation over results. But also, the true high-efficiency creators prioritize their tools over everything. To be truly efficient and to get in the flow, you need tools that work with your particular style and approach. This is why there are lots of idiosyncratic tools and opinions about tools out there. Since not everyone works the same way or has the same preferences, there’s a natural market for unique tools that work differently to suit all those people. The “religious wars” over editors are really just people missing the point and arguing for no reason. Emacs is better for some people. Vim for others. Vscode for others. Notepad++ for others. Nano for others. This is a good thing.
If you don’t care about your craft or workflow enough to care about what tools you use, I wonder what level of quality you can achieve.
I agree to an extent that tools are not important.
But, for me, there is a certain threshold that a tool must pass to be useful. A tool that is below this level is only slowing you down or limiting your abilities.
You wouldn't use a knife to tighten screws if you have a perfectly good screwdriver lying around. And there's little to no advantage of buying a new expensive or over-engineered screwdriver.
I believe, plain vi is the lowest I can go for writing code. That doesn't mean that I can't use notepad or nano, but they fall under the level of being useful and only cripple and slow me down.
Ghostty passes this level of usability for me, but personally I'm fine with st - no gpu, no cpu spikes, uses barely any ram and still feels snappier. So, what's the point?
When Ghostty was publicly announced, I used it for a few months and gave up on it due to the lack of support for the CMD+F feature that I use Terminal.app. This is a critical feature for me while tailing logs on my local. I tried the workaround of capturing the text into a text file and then searching it. It just didn't work for my workflow and dropped it. Ghostty is great otherwise. But, without the CMD+F, it's of no use to me.
> Ghostty 1.3 is around the corner, literally a week or two away, and will bring some critically important features like search (cmd+f), scrollbars, and dozens more. In addition to GUI features it ships some big improvements to VT functionality, as always.
Same. Lack of search and lack of scrollbars make me wonder why this project got so much attention in the first place. iTerm2 seems way more capable.
I suspect it is "just" the very nice-looking default theme in Ghostty. I updated my iTerm2 colors with colors I picked from Tailwind‘s excellent color palette and iterm2 now feels fresh and has all the features I want.
Mitchell’s attempts at more correctness and better speed, plus the no-nonsense UX. iTerm2 is confusing and overwhelming and bloated for those of us who just want a terminal that works.
Note in Ghostty 1.3 we disable discretionary ligatures (I think dlig/calt) by default as recommended by font standards. We still enable liga though that usually contains far less controversial ligatures.
My only issue with ghostty is it isn’t immediately recognized by some programs through ssh (eg less) and they don’t operate properly. However there’s a one liner that solves the problem permanently on the remote machine[0] so it isn’t too bad. Hopefully in the near future ghostty’s terminfo will be shipped with common linux distros.
I find this docs page fairly hilarious. Complaining about how the rest of the world is in the stone ages, and that is why ghostty doesn’t work with it.
For me, a terminal program that requires me to muck with every machine I log into to get it to work is pretty horrible. I connect to a lot of different machines every work dat. Often they’re not machines I maintain. Making that harder is exactly the opposite of what I want from a key tool like a terminal program.
Note: Ghostty follows the same pattern as Kitty where they a) use their own terminfo, b) distribute it when ssh'ing (it gets pushed to the remote server) and c) added it to ncurses so that it will eventually go away.
Apparently changing $TERM from `screen-256color` to `tmux-256color` in tmux to try and get italics working in nvim totally mangled ghostty.
I looked into infocmp and other tricks to try and and figure out why the backspace key was throwing gibberish around, but I had no interest in debugging such an inscrutable thing through so many layers.
I don't fault ghostty for things like this, but at the same time it's hard not to scorn the tools you want to be invisible, even if making unreasonable demands of them on accident.
First, libghostty is _way more exciting_ nowadays. It is already backing more than a dozen terminal projects that are free and commercial: https://github.com/Uzaaft/awesome-libghostty I think this is the real future of Ghostty and I've said this since my first public talk on Ghostty in 2023: the real goal is a diverse ecosystem of terminal emulators that aim to solve specific terminal usage but all based on a shared, stable, feature-rich, high performant core. It's happening! More details what libghostty is here: https://mitchellh.com/writing/libghostty-is-coming
I suspect by the middle of 2027, the number of people using Ghostty via libghostty will dwarf the number of users that actually use the Ghostty GUI. This is a win on all sides, because more libghostty usage leads to more stable Ghostty GUI too (since Ghostty itself is... of course... a libghostty consumer). We've already had many bugs fixed sourced by libghostty embedders.
On the GUI front Ghostty the apps are still getting lots of new features and are highly used. Ghostty the macOS app gets around one million downloads per week (I have no data on Linux because I don't produce builds). I'm sure a lot of that is automated but it's still a big number. I have no telemetry in Ghostty to give more detailed notes. I have some data from big 3rd party TUI apps with telemetry that show Ghostty as their biggest user base but that is skewed towards people consuming newer TUIs tend to use newer terminals. The point is: lots of people use it, its proven in the real world, and we're continuing to improve it big time.
Ghostty 1.3 is around the corner, literally a week or two away, and will bring some critically important features like search (cmd+f), scrollbars, and dozens more. In addition to GUI features it ships some big improvements to VT functionality, as always.
Organizationally, Ghostty is now backed by a non-profit organization: https://mitchellh.com/writing/ghostty-non-profit And just this past week we signed our first 4 contributor contracts to pay contributors real money! Our finances are all completely public and transparent online. This is to show the commitment I have to making Ghostty non-commercial and non-reliant on me (the second part over time).
That's a 10,000 foot overview of what's going on. Exciting times in Ghostty land. :) Happy to answer any big questions.
What has it been like witnessing terminal emulators make such a huge comeback with the advent of Claude Code et. all? I remember comments here in the early days of Ghostty along the lines of "Why is he working on a terminal emulator? We need people working on future problems, not the past!" Pretty funny considering I regularly hear people say they are in the terminal more than the browser now. Crazy times!
If you told me 3 years ago that terminal usage would _increase_ I would've laughed. Beyond that, I'm now having regular conversations with the frontier agentic coding companies (since they're far and away the largest terminal users at the moment) and if you had told me 2 years ago that that would be happening because of a terminal, I would've laughed even harder.
So, it's amazing. But overall, its amusing.
The large language changes are a burden, but it's something I knew going into it. And so far in every case, it's been well worth it. For example, 0.15 introduced the std.Io.Writer overhaul, but I really love the new API. I haven't started the std.Io change yet for 0.16. We'll see. And honestly, LLMs make this all way less painful... even though they're not trained on it, agents are able to run builds, reference docs, and work their way through the upgrade with huge success.
I thought that finding contributors would be an issue, but it hasn't at all. There's a lot of people out there eager to use Zig, the language isn't hard to learn (as long as you're already familiar with systems concepts), etc. It has been good.
I'll think about more to say if I write about this more but overall, I'm very happy with the language, the community, and the leadership. All good.
It was so easy to get the terminal functionality going with `libghostty`. Most time was spent building the functionality around it.
Thanks for making it.
[0]: https://github.com/weedonandscott/trolley
If so that actually sounds really cool. I'd like a dedicated lazygit app in my tray at all times.
Project mentions Windows compiles but isn't tested. Do you have a gut check on what issues there might be?
It also got me wondering how things would be different if you haven't crossed paths with the guy who unplugged your mouse :) It's fascinating how life is full of these small yet defining moments. We don't always appreciate them right away, but beautiful to look back.
Thanks for Ghostty! It has been my daily terminal driver for the past year.
[1] https://www.youtube.com/watch?v=WjckELpzLOU
It’s common for me to have 15-25 different terminal windows open for using Claude code. I shifted to Ghostty because I was looking for more features.
Unfortunately, none of the features I wanted are available anywhere (though I’ve come to appreciate Ghostty anyway). Here’s what I had wanted:
1. Basic text editing features (ie click to place cursor in the text input field; highlight to delete)
2. Change colors or fonts mid session (to make it easier to find particular windows)
3. Window management and search (eg, a way to find my windows when I lose them and to otherwise control them)
Apparently, it is really hard to develop features like these for terminal emulators. I’d love to understand why…
As for editing text, ghostty+tmux most definitely supports editing text with the mouse (even an in terminal right click menu!) although sounds like your intended use of select to delete isn’t common so you’ll need to do some customizations.
I recall the package manager war of Haskell between "stack" and "cabal-install":
Users would have strong opinion depending on their background.
But the developers eventually made both projects use the same libraries.
Both tools allow for ghcup to manage the compiler, so there's no conflict there.
The difference is eventually just a frontend experience, and all the heavy lifting and synergy is achieved behind the scenes.
I would not have believed the same is possible for terminals, even cross-platform, so thank you for having this vision.
Let's say I'm the creator of Alacritty, would I have more problems adding libghostty than it's generically named identical counterpart libtermengine?
The real goal isn't for Alacrity or Kitty or WezTerm or any other terminal to use libghostty. I think over the long term, terminal emulator user bases dwindle down to niche (but important) use cases.
The real goal is for higher-level tooling (GUI or browser) that utilizes terminal-like programs to have something like libghostty to reach for. I think this represents the much, much larger ecosystem out there that likely touches many more people. For example, Neovim's terminal mode, terminal multiplexers, PaaS build systems, agentic tooling, etc. You're seeing this emerge in force already with the awesome-libghostty repo.
libghostty would still be useful for traditional terminal emulators to replatform on, and for example xterm.js is seriously looking into it (and I'm happy to help and even offered their maintainer a maintainer spot on libghostty). But, they're not the goal. And if fragile egos hold people back, it's really not my problem, it's theirs.
Just that it's a specific "product"-y sounding name? Would you also be concerned about "libwayland" vs "libcompositor"? Genuinely curious: this seems like an insightful question, I just don't follow the reasoning.
I'm sure you feel the same watching Ghostty become what it has. Big thank you.
Tabs (and panes? I haven't tried yet) should work fine for regular terminal windows though.
I’ve been trying to figure out how I could actually help him distribute it and I keep coming back to the best option being to wrap his programs terminal output into a host process that can emulate and render it. It seems that the lib Ghostty might be perfect for the former, but not quite yet on the latter?
that might be a viable approach for you
[0] https://www.reddit.com/r/macapps/comments/1loiw2z/comment/n0...
I've been waiting for the vim feature to hit stable, and have just been checking to see if there's a new release every so often, but I couldn't find a discussion or anything to see when it was planned.
I was a long-time Kitty user, but switching to Ghostty has been a big upgrade for my workflow. Hard to go back now. Thank you
Essentially, I have a few features that have a TUI-first UI, and the obvious next step is to expose some of that to a browser.
Out of curiosity, does ghostty do the Quake terminal thing - I use yakuake for this, but it feels a bit long in the tooth.
This works on MacOS, and on Linux sometimes:
> On Linux, the quick terminal is only supported on Wayland and not X11, and only on Wayland compositors that support the wlr-layer-shell-v1 protocol. In practice, this means that only GNOME users would not be able to use this feature.
Deleted Comment
Dead Comment
Dead Comment
Dead Comment
Nice! Looks like I should have rushed the interview. :D
Big fan. Can I get a ride on your jet?
WezTerm has everything I need and is closest to iTerm2, minus being able to quit it and have it restore all windows and tabs on restart -- but oh well, it's not an important enough feature. It also renders my prompt perfectly; no small pixel divergences like all other terminals have.
Kitty I don't remember why I rejected.
Alacritty I like but the lack of tabs is not acceptable for the moment... and before you ask: I hate tmux. So much more key presses to achieve basic functionality, it boggles my mind why people love it. But, to each their own obviously.
It's also likely I'll settle for some Linux-exclusive terminal but as I'm not yet possessing a Linux workstation (just a laptop) I haven't put the requisite time to do this research.
Suggestions are welcome.
Maybe worth another look at then? I'm far from a Kitty power user, but it does pretty much everything else I want it to, including working as a quake-style terminal[0]. And you can extend it with kittens[1] if you so desire. Also, the next release should presumably include smooth scrolling[2] which I'm quite looking forward to.
Maybe more than any one feature though, I appreciate the hard work that Kovid (the creator of Kitty) has done to tastefully add new VT standards and try to make terminals as useful as they can be in the 21st century.
[0] https://sw.kovidgoyal.net/kitty/kittens/quick-access-termina...
[1] https://sw.kovidgoyal.net/kitty/kittens_intro/
[2] https://github.com/kovidgoyal/kitty/pull/9330
Ctrl+Shift+G wraps the output of the previous command into a pager (say, less). You often only know you needed a pager after that output is printed.
Ctrl+Shift+E highlights all links on the current screen and assigns short alphanumeric codes to them, so you can open links without using the mouse. For example, `Ctrl+Shift+E 1` opens the first link, `.. 2` the second one, etc.
Ctrl+Shift+U opens symbol search where you can find & insert symbols using their unicode names. Emoji, TUI blocks, rare accented characters you need once in a blue moon, CJK ideographs, whatever.
WezTerm is a very good replacement.
For instance, in vim the F3 key was broken[^1]. It was very surprising and weird, and a portable workaround required some arcane vim configuration.
Another important pain point was that the font rendering was different in Kitty to any other app, and very dependent on the screen DPI. IIRC, for a DPI around 100, I had to switch to "legacy rendering" because the default rendering was barely readable.
I also remember issues with SSH. And Kitty crashed at least once. And I wasn't a fan of Kitty's mix of C and Python. After a week or two of usage, my Kitty config file was big, with an extra hundred lines of Python for the tabbar. Despite some nice features (like the shortcut to put the output of the last command into a file), I got uneasy with all this mess. I tried Ghostty, which was as good as Kitty with much less oddities.
[^1]: https://github.com/vim/vim/issues/13328
I also use vim (well neovim) as my primary editor, and have set up tmux to integrate well with it, so that might contribute to my appreciation and continued usage of it.
But you do have to run a proper window manager so you don’t have to require tab support in every single app. ;)
https://github.com/ghostty-org/ghostty/releases/tag/tip
https://github.com/borisfaure/terminology
Its "moment" as a new novel terminal was over a decade ago, but it still chugs on working just fine. Notably(?), gregkh uses it (or used to use it):
https://www.linuxfoundation.org/blog/blog/greg-kroah-hartman...
Another option is to leave the tabbing to your window manager.
I do use tabs rather than repeatedly switching tmux sessions, but I do end up running tmux for splitting the GUI into side by side layouts.
I like the idea of tmux but as another poster suggested, I prefer to just get better at my window manager to achieve similar results. tmux requires way too many key presses for me.
Surprised none of the other commenters have mentioned zellij. I work across windows (WSL) and linux so really like having the same set up for both, which means no Ghostty/Kitty since they don't support windows.
Zellij is a lot smoother and nicer looking out the box, and its key shortcuts are pretty intuitive. There's a lit of advantages to not having an extra layer, but zellij + alacritty is definitely worth having in your list of options!
https://zellij.dev/
BTW is there feature parity between macOS and Linux, e.g. scrollback buffer searching on Linux?
Tabs usually mean mouse+click to switch which takes way more effort that a simple alt+number or similar keybinding used to switch "tabs" in tmux. I'd guess that some terminal emulator tabs allow keybindings to switch tabs as well but, modelling OP, I'm focusing on the expected default experience.
I hate mixed mouse + keyboard workflows as well.
https://github.com/kovidgoyal/kitty/issues/2084
You can turn on a feature documented as allowing the terminal to be controlled by escape sequences, but then output of programs can control the terminal! Whoop-de-do.
AI Usage Policy - https://news.ycombinator.com/item?id=46730504 - Jan 2026 (273 comments)
Finding and fixing Ghostty's largest memory leak - https://news.ycombinator.com/item?id=46568794 - Jan 2026 (138 comments)
Why users cannot create Issues directly - https://news.ycombinator.com/item?id=46460319 - Jan 2026 (310 comments)
Ghostty is now non-profit - https://news.ycombinator.com/item?id=46138238 - Dec 2025 (289 comments)
Ghostty compiled to WASM with xterm.js API compatibility - https://news.ycombinator.com/item?id=46110842 - Dec 2025 (115 comments)
Vibing a non-trivial Ghostty feature - https://news.ycombinator.com/item?id=45549434 - Oct 2025 (147 comments)
Ghostty 1.2.0 - https://news.ycombinator.com/item?id=45252026 - Sept 2025 (26 comments)
AI tooling must be disclosed for contributions - https://news.ycombinator.com/item?id=44976568 - Aug 2025 (464 comments)
We rewrote the Ghostty GTK application - https://news.ycombinator.com/item?id=44905808 - Aug 2025 (224 comments)
Release Notes for Ghostty 1.1.0 - https://news.ycombinator.com/item?id=42884930 - Jan 2025 (79 comments)
Déjà vu: Ghostly CVEs in my terminal title - https://news.ycombinator.com/item?id=42562743 - Dec 2024 (55 comments)
Ghostty: Reflecting on Reaching 1.0 - https://news.ycombinator.com/item?id=42527355 - Dec 2024 (7 comments)
Ghostty 1.0 - https://news.ycombinator.com/item?id=42517447 - Dec 2024 (681 comments)
Ghostty 1.0 Is Coming - https://news.ycombinator.com/item?id=41914025 - Oct 2024 (32 comments)
What are you talking about? What UI does Kitty have?
I really like this a lot.
You see it on all hobbies, e.g. when the someone sees a photograph and their first question is about what camera and optics were used. No question about composition, light, the moment, creativity... they only care for the tools.
The technique and knowledge is the important thing, not the tools. They forget the good practitioner can do a great photo with a $200 phone than they with the best Canon DSLR.
I have seen this in all hobbies I have practiced, be it musical instruments, kolinsky brushes on miniature painting, montain bikers, running apparell...
As I'm getting older I care less about editors, terminals, Linux distros... and after seeing what can be done with agentic coding tools less so.
there is definitely a tendency for noobs and amateurs in any hobby or industry to obsess over expensive gear and things that don't matter (I love the term "buyhard" for it). you're out of your mind if you think the professionals in literally any industry do not discuss the specific technical tradeoffs of tools they are using among themselves.
-- Pablo Picasso
FWIW once I found my workflow (vim + tmux) I stopped caring so much about chasing "new" tools. Now have the luxury to wait 3-5 years and see what's worth adopting, most of it isn't only because I already found a workflow that works for me; but if you're new or still finding what works best, you'll always be experimenting.
https://jazzfuel.com/charlie-parker-the-plastic-saxophone-th...
But "fake it until you make it" is part of life too and everyone wants to belong and to be taken seriously. You can't always just "do the hobby for fun" if you want to be social since anxious intermediates whose own output is still crap will gate-keep.
If you can, find hobbies that bring you joy and do them alone, free from the influence of too much right and wrong, at least in the first stages.
In the context of terminal emulators, idk, do something like learn AWK purely for personal enjoyment. You may not have the flashiest dotfiles or color schemes or whatever, but you'll be able to do arcane stuff in the terminal that will give you confidence you belong and others will be amazed by.
This isn't directed at you, of course. Just a weird observation where people are prescribing their workflows to others and telling them what they should or shouldn't care about when the only thing they know about their workflow is that they use a terminal at least once a day.
I wish I could get out of the habit of opening Vim in VSCode's terminal window but sometimes I'm tweaking something that's "not part of this thing" and it kind of makes sense that way.
If you don’t care about your craft or workflow enough to care about what tools you use, I wonder what level of quality you can achieve.
But, for me, there is a certain threshold that a tool must pass to be useful. A tool that is below this level is only slowing you down or limiting your abilities.
You wouldn't use a knife to tighten screws if you have a perfectly good screwdriver lying around. And there's little to no advantage of buying a new expensive or over-engineered screwdriver.
I believe, plain vi is the lowest I can go for writing code. That doesn't mean that I can't use notepad or nano, but they fall under the level of being useful and only cripple and slow me down.
Ghostty passes this level of usability for me, but personally I'm fine with st - no gpu, no cpu spikes, uses barely any ram and still feels snappier. So, what's the point?
https://github.com/ghostty-org/ghostty/issues/189
https://x.com/mitchellh/status/1993728538344906978
As Mitchell stated above:
> Ghostty 1.3 is around the corner, literally a week or two away, and will bring some critically important features like search (cmd+f), scrollbars, and dozens more. In addition to GUI features it ships some big improvements to VT functionality, as always.
I suspect it is "just" the very nice-looking default theme in Ghostty. I updated my iTerm2 colors with colors I picked from Tailwind‘s excellent color palette and iterm2 now feels fresh and has all the features I want.
Deleted Comment
https://github.com/0xType/0xProto#4-ligatures-that-dont-defo...
I can't recommend 0xProto enough, the only thing I'm sorry about is that I didn't find it sooner :)
[0] https://ghostty.org/docs/help/terminfo
For me, a terminal program that requires me to muck with every machine I log into to get it to work is pretty horrible. I connect to a lot of different machines every work dat. Often they’re not machines I maintain. Making that harder is exactly the opposite of what I want from a key tool like a terminal program.
Kitty needed to do it too back in 2018.
https://lists.gnu.org/archive/html/bug-ncurses/2018-09/msg00...
Note: Ghostty follows the same pattern as Kitty where they a) use their own terminfo, b) distribute it when ssh'ing (it gets pushed to the remote server) and c) added it to ncurses so that it will eventually go away.
I looked into infocmp and other tricks to try and and figure out why the backspace key was throwing gibberish around, but I had no interest in debugging such an inscrutable thing through so many layers.
I don't fault ghostty for things like this, but at the same time it's hard not to scorn the tools you want to be invisible, even if making unreasonable demands of them on accident.