Mitchell,

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!

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.

Right? It’s been kind of funny watching everyone “rediscover” the terminal and I’m over here feeling like a true graybeard “silly kids, I’ve been here the whole time.”

What’s old is new again is apparently just as true in tech as it is in fashion.

The terminal was _always awesome_, the bar to realized that was just a tad high for many people. Until now!

here-doc usage has probably 100x-ed in the last year

It's 1,000,000,000,000x easy. Have found enough annoying bugs in powershells implementation of it that I know nobody is using it.

How so?

It's because the web developers who destroyed the web are now taking their mess with them into more obscure places, such as terminals, hardware and AI.

That's probably why it is so hyped up as it is right now.

Embrace, Embellish, Enshittify.

Why the hate against web developers?

Because of all the laggy javascript, wasting precious compute and gigawatts of power just to make buttons dance, track us and shove ads up ours?

Websites used to be below 100KiB - now they come with MEGABYTES of obfuscated JS.. wtf

Though obviously, it's not the individual developer to blame but the incentive system.

The HN zeitgeist has something of a love/hate relationship with the web, I've noticed. HN in general seems to skew a little older than a lot of online communities, so a lot of HN users were adults back in the early days of the web/Usenet/etc. There's a tendency to view those days with nostalgia, leading a lot of people to feel like the "good old days" of the web were "ruined" by the modern shift into more interactivity, fancier/prettier design, etc. And "web developers" are the ones proximately responsible for the shift, so they get the hate too.

I laugh every time I see someone on HN asserting that the web "shouldn't" be used for anything beyond "documents and lightly interactive content", which is not uncomment. There's some real old-man-yelling-at-clouds energy there.

It basically boils down to: (a) 90s web developers tended not to have computer science backgrounds and weren't aware of fundamentals -> (b) when js frameworks exploded in popularity and diversity in the 00s, there was much wheel reinventing, because those developers (and to a lesser degree framework inventors) were often ignorant of wheels -> (c) there are persistent, fundamental mistakes* in the web ecosystem that could have been fixed at the start if anyone with experience had been asked.

All of those people are now the vibe coders of the 20s, and it's going to end up in the same dumpster fire of 'Who knew it might be a good idea to cryptographically sign and control library packages in a public repository?'

* Note: I'm distinguishing things going sideways despite best intentions and careful planning from YOLO + 'Oops, how could that possibly have happened?' shit

Have you used the web recently? It’s a mess. Most sites don’t actually work well. Everything is slow and bloated and ad-filled, pulling hundreds of megs from hundreds of hosts to display a single page covered in popup alerts, subscription begs, cookie warnings, and paywalls.

Yeah it’s been amusing to see people rediscovering tmux as well

I think terminal workflows are intimidating for a lot of people, because the discoverability is lower than GUIs. You can't necessarily intuit how a CLI works, you have to read the documentation or watch a tutorial, which my 10 years in the IT industry has taught me a big barrier even for really experienced SWEs. The new coding TUIs are a more gentle introduction to that.

> ... because the discoverability is lower than GUIs.

The UI paradigm created by the emacs transient package [1] can improve the discoverability of CLI commands significantly. It's one of the components of magit, the famous git frontend, that makes it so awesome. It's discoverability is very close to that of GUIs and somehow even more pleasing to use than GUIs. I wonder if someone is trying this on terminals.

[1] https://github.com/magit/transient

I think people simply don't like to read or write. --help is probably as discoverable as it gets.

The program perhaps most responsible for the renewed interest in the terminal, Claude Code, is made with React. Life moves pretty fast.

I remember the first time I heard a girl use the word "lol" (early 2000s) and thought to myself: Normies have hit the internet.

I've used a terminal as my main interface FOREVER, and I'm amazed that people are joining this healthy habit of interacting with the computer as CREATORS.

Vibe coding is the first thing I’ve seen that has normies using the terminal

Once he fixes the past he will have more time to fix the future

He was on a podcast recently where he talked about that a little. It’s on Youtube.

Overall I would describe it as "amusing."

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.

Would a terminal deal with them have added another billion to your account if it hadn’t been nonprofit?

Probably not. I don't know. Who cares.

/* 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! */

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.

Also it 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. It's hard to 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

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

I subscribe to the channel, so I had already downloaded the episode. But glad PE is getting some algorithm-love; it's a great channel/podcast. Gergely is a great interviewer.

https://www.pragmaticengineer.com/

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.

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?

Maybe as an SSH app? See https://snakes.run for a recent example.

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?

somehwere else in this thread this project was mentioned (uses libghostty): https://github.com/weedonandscott/trolley

that might be a viable approach for you

Never heard of this, thank you!

I'm the author of Trolley[0] (Electron for TUIs).

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

I'm not quite understanding your project. What is the use case? Is this so I can package up an existing terminal app as a dedicated desktop app?

If so that actually sounds really cool. I'd like a dedicated lazygit app in my tray at all times.

Yes, that's it. It came about after writing a small TUI for a friend to back up their Vimeo library. They liked the simplicity and speed but not having to use the shell. Didn't want to install Ghostty either.

So here we are

This is kinda cool. Thanks for sharing.

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?

I think it may actually work. It's just that I only have a VM to test it on, and it does not support OpenGL. I got it to compile and run, but it crashed on that VM limitation.

Feel free to open issues in the repo, I'll find a way to get a Windows machine if there's interest.

You can also email me at `trolley [at] wands [dot] is`

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.

What makes you say that isn't the job the emulator? Sure it is. In fact, tmux itself is a terminal emulator that you just so happen to run inside of another terminal emulator that you want to multiplex.

I’ve been using scroll back search for 15+ years with Terminal.app and iTerm2, and there’s no way that’s not the job of the terminal. You don’t know how good that is until you use it.

What am I missing?

Tmux does it better

+1

For 1, take a look at https://github.com/alex-903/zsh-mouse-and-flex-search. It runs as a zle-line-init hook, so it works in any terminal. A full terminal app implementation would be cleaner, however.

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.

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?

can you make cmd+f work please

while I agree, the comment you just replied to says:

> 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

It works well enough that I didn't realize I've been on the nightly channel since it appeared, too!

FYI: It is working in nightly!

Thanks for your awesome work. Never thought I’d switch to a terminal without cmd-f, but ghostty made it worth it. Can’t wait for v1.3!

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.

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

[0] https://www.reddit.com/r/macapps/comments/1loiw2z/comment/n0...

Fwiw x the program alt-tab on Mac gives macOS a more sane alt-tab behavior.

Cmd+` is also a useful shortcut for switching between windows of the same application

Congrats on creating and helming such a cool project!

Out of curiosity, does ghostty do the Quake terminal thing - I use yakuake for this, but it feels a bit long in the tooth.

It does. See https://ghostty.org/docs/config/keybind/reference#toggle_qui...

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.

I use it on MacOS, but it doesn't support tabs.

> front page

Nice! Looks like I should have rushed the interview. :D

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.

That's super interesting to hear. I see people say all the time "oh I would never use it in a big project because it's changing so fast", but then see awesome projects like Ghostty and Tiger Beatle written in it, so clearly they're doing something right.

I'm surprised to hear LLMs have been helpful. What little I tried to use them for with Zig, all the information was way too out of date. But I was mainly just doing research, not running an agent at the time, so that's probably why.

Yes, LLMs with Zig are absolutely useless without agentic behaviors. Throw an agent in the mix and it's totally fine. Bonus points if you pair it with some basic agent skills so it knows how to look up language references, stdlib files, etc. then it does even better.

I'll have to give it another try the next time I play around with Zig. I decided to let all the big changes with IO and what not play out before diving back in lol.

I've been slow on the agent pickup. The ethical issues really bother me (LLMs in general), though it's clear I'm not gonna have a choice in this industry so I've been caving recently. The persistent narrative that agents can build entire complex software systems is also irritating, because that clearly doesn't seem to align with reality.

Would you mind sharing or pointing me to any links that explain how you've set up Zig to work effectively with LLMs using agentic features?

I was thinking that downloading the full official documentation, separated by sections inside the repository someone is working on with Zig, could be useful, but maybe there are more optimal ways to approach this.

Thanks.

Do you get frustrated in using a low training data language like zig with AI models? I've noticed that models tend to be better with languages like TypeScript than Swift because of issues like that.

Not at all. Give it tools and skills and it figures it out very quickly. Must be an agent. Don't use chat.

Hi,

Big fan. Can I get a ride on your jet?

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.

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.

Zellij has been holding me over with tabs and panes (in quick terminal) while I wait for them to come to ghostty directly.

Tabs (and panes? I haven't tried yet) should work fine for regular terminal windows though.

There's a PR out there for tabs in quick terminal https://github.com/ghostty-org/ghostty/pull/9857

Did a double take on this one since my Ghostty has had panes for a while now (I run tip/nightly). Didn't realize it's not part of the current release.

Also, Zellij is nice.

Ah I just started using ghostty maybe a week ago and I mostly use quick terminal so I might be missing the panes on the regular windows.

Just to clarify, it's more about the ability to run a terminal on my Linux box and connect and disconnect to it from my Mac that I'm looking for. Wezterm does a good job of this. Previously I was using tmux and mosh and Nebula, and that worked really great for reconnecting (I almost never had to reconnect, it just stayed live, wezterm I need to reconnect all the time, but that works reliably). But copy-paste with tmux is meh.

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!

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

Genuine question: what are the ghostty features that make it a big upgrade coming from Kitty?

Seconding that question!

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.

find is provided by the OS, not a terminal emulator like Ghostty. Most likely something is wrong with your paths.

I think they mean like CTRL+F kind of find.

This is addressed in paragraph 5 of the post they replied to.

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.

Nvm. Had another look, and I think I found it? Is it this: https://github.com/ghostty-org/ghostty/milestone/7

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.

New stable release in 1 to 2 weeks.

Fantastic thankyou.

can you please make a Windows version!!

What's the current state of the art with using libghostty in a browser? There are a few community projects around that compile it down to wasm.

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.

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?

Cmd+F ! Thank goodness!

Do you think there's entry barrier, even if pride based or psychological, to the fact that libghostty is called so rather that something more generic?

Let's say I'm the creator of Alacritty, would I have more problems adding libghostty than it's generically named identical counterpart libtermengine?

I'm not concerned with it.

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.

Thank you for you answer, I had misunderstood the main objective of where it was meant to be applied, this makes sense!

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.

Disclaimer: I am not the maintainer of anything terminal related, it's just an intuition.

Let's say I'm the creator of ghostty "competition".

The fact that is has the same name, could feel if I change that:

- Maybe my users start thinking why don't I use ghostty instead - Will the maintainers of libghostty chose more oriented to ghostty than for my terminal?

It's a half assed analogy, but think if Google's V8 would be called ChromeEngine instead of V8.

Can you please add an rss feed to your blog? Thanks for the amazing work

thanks!

I came to Ghostty for the icon, but stayed because of the experience, the philosophy and your dedication and enthusiasm. Thanks!

> 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.

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

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.

bro please update ur support for not gtk DE please