Interview With Mitchell Hashimoto

Interview With Mitchell HashimotoJul 2026 - Alex AlejandreMitchell Hashimoto was behind Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint and now builds Ghostty and Vouch.In this interview, we talk about terminals, Zig and open source.You’ve been interviewed a lot. Why do people like to interview you?In interviews, everyone comes from a different angle. Many people want to know how the software engineering to business founder mindset transition went. Then others are interested in product stuff, the work I did at Hashicorp or Ghostty now. What’s different here is there’s no known agenda coming into it; neither of us have anything to sell.What do you find so fun about terminals? Like, why Ghostty?I spent ~15 years building CLI applications (not TUIs like we see nowadays). Through that process, I accidentally learned how to color things, move cursors etc. Leaving Hashicorp, I wanted to sharpen my technical skills (where they’d grown dull from neglect) and specifically work on: Pre-AI GPU programming, desktop/single node systems programming (spending so much time on the distributed side where you didn’t worry about cache locality or vector operations, since network costs dominated). I also really wanted to play with Zig. I wanted to satisfy those 3 things.After 15 years building CLIs, I didn’t understand how a terminal emulator worked. I knew the components of a terminal but really wanted to understand how it worked, which would also let me work on the GPU, desktop and in Zig. My goal was to run vim and the compiler in it, have it build itself, then throw it away. But as I learned more about the terminal ecosystem, I understood nothing fit the niche I wanted: fast, feature-rich and natively cross-platform. I shared it with a few friends in Discord, who asked if they could share it with others because they were actually using it every day. The Ghostty Discord was just my friends’ group chat which got repurposed. I didn’t want to publish because my public persona would generate too much undue attention, so I ran a private beta for a long time.How can we push terminals harder?I don’t support pushing terminals to the extreme.

Sure, they’re an application platform capable of the same things other application platforms on top of the OS are like the browser, old Java app runtime environments. You could build all functionality into it: video and microphone access, responsive layouts… You could.But the browser is good at something, the desktop is good at something else and text-based (monospaced-grid) applications are also good at something unique. These text-based applications should be quick to implement, easy to interact with, clear in their security model. There’s a lot of opportunity in the ecosystem here and I’d love to build more protocols to enable that.Terminal-based applications lend themselves to composition better than other paradigms. TUIs less so, but most CLI tools have mechanisms (beyond stdin and stdout) to use them like a function (the UNIX do one thing philosophy is the extreme). Neovim and AI tooling offer ever more cmdline flags. A world of better terminal applications, is a world of better automation, scriptability.I want to make the terminal a special place for applications. The PTY’s in-band signalling (an unstructured byte stream with escape sequences) is a big problem. The Nushell ecosystem tries to fix it with another layer, but we need a fundamental improvement. Many people dislike the Microsoft ecosystem, but PowerShell gets a lot right with structured data.What do you think about non-legacy terminal APIs?My guiding star is how we now have multiple major, huge application platforms: the browser, emacs, the whole Apple ecosystem, Microsoft ecosystem, Android, video game console platforms. These ecosystems have strengths and weaknesses, but how do their frameworks work? On the web, it’s the DOM and JS APIs. On Apple, it’s AppKit, Cocoa and SwiftUI. On Windows, it’s Win32, WinUI etc. On Linux, it’s GTK and Qt etc. When someone says we need a better way of accessing clipboard data (historical protocols are text only, what about images, multiple MIME types etc. which desktops have handled for decades), I would grab the docs for clipboard managers on every platform to see what we’ve landed on. There’s no reason for us to build something based on our own understanding without researching decades of prior art. That’s the approach I’m trying to take here. I’ve not introduced any custom protocols yet.Two protocols scream at me.

Currently, terminals have a main screen and an alt (sometimes called primary and secondary) with different properties. Main screen is like your shell with scrollback etc. and the alternate screen is like Neovim, most TUIs etc. There are only 2, you either turn a mode on or off putting you into primary or secondary (taking up the whole screen, losing scrollback etc.)I’d like to introduce an n-screen API to create and populate an unlimited number of screens in the background, let you overlay screens with separate grid sizes etc. The terminal emulator could handle line wrapping, selection, routing mouse events etc. You could specify a screen as a standalone window which the terminal emulator renders outside of the grid - imagine your Neovim tabs being native window tabs opened at the same time! This foundational layer would solve a lot of things.I also have a spec’d out button protocol. Currently, there are mouse protocols to get notified when someone clicks a grid cell. But you only receive events for what’s currently on the screen, not history, when things scroll back… We currently support hyperlinks (OSC 8) and I’d like something similar to OSC 8 where clicking sends a message (which you specify) to the program. You could create a button with an open_profile ID which will still register when the user scrolls back in history. This affects main screen applications (the only ones with scroll back) like Claude Code. I have no interest discussing AI here, it’s just a really popular main screen application. The moment things go into history, you lose the ability to open files, in-app links etc.To what extent is that just redoing the entire user space? There’s a lot of room for scope creep there.I experimented with replacing the entire pty protocol with Wayland. If you squint, a terminal’s just a windowing server, managing windows and widgets on windows. I studied Wayland to make Ghostty run better on it and thought it’s a pretty good protocol for what it tries to solve (local desktops, rendering windows). But I threw that out.A problem with terminals is that there’s no standards body any more. There are old specs, de jure standardized, but the past 20 years have seen standardization based on what the most popular terminals do. We have a hodge-podge of features, but no entity pushing a tasteful vision.

I don’t know what the right path forward is. You could make an alternate home for text-based applications, not called a terminal anymore, build something new (with a terminal translation layer on top to bring legacy applications on) which is trying to do something different.How do you balance these ideas with users’ day to day demands?I’m very public about open-source maintainers having 0 obligation to users. The first line in OS licenses is “as is, no warranty”. That’s the agreement, you get free software and can’t make demands on it. But I like striving to build good software (some may disagree and say my software’s shitty), so I do feel an obligation to fix problems, to make the software better.Some days I wake up expecting to go through issues just fixing other people’s problems. But sometimes I wake up and focus on what I want, not reading a single issue, discussion nor PR. Sometimes, you need to push the bigger vision; sometimes, you need to address the reality on the ground.You can build a perfect city in the sky, then come back and find terror and suffering in the real world. So you need to clean that up sometimes.If all I did was pick through user issues every single day, you’d get stable, stagnant software. If you accept all PRs, you will change but without vision. I don’t mean to insult contributors, but only one person every few years fundamentally gets it. Most contributions just scratch someone’s specific itch, accepting them all leads to a mountain of code. Really understanding, you can sometimes discover graceful systems which solve everything succinctly.I once did feature design video where I closed 3-4 separate feature requests solving people’s individual problems, because a single feature (different from all of them) could solve them all at the same time. Very few people can do this, not because it’s difficult but because it requires a level of care few people give to other projects.I’ve been thinking about this off and on for like a year (along with hundreds of other things, nothing dedicated, I’m always just thinking about this stuff when not at a computer). When I finally sat down and thought “I’m going to solve this,” maybe… 1 hour?

https://x.com/mitchellh/status/2003957851514126510Fewer features composing better attracts people to exotic programming paradigms. It demands a lot of perspective.I got on an internet spat with someone recently about my philosophy. One of the highest requested Ghostty features is search, which is done and shipped. But someone complained search bloated and broke Ghostty’s minimalism. I advertise Ghostty as feature rich! But I do distinguish that from bloat. I don’t think you should have to pay for the things you don’t use (besides disk space or resident code memory). I explained the way I architected search means it will take up disk space and be loaded into RAM but nothing will execute; this is a free feature if you don’t use it. I want Ghostty to be a riceable, customizable terminal fitting peoples’ needs, but also working out of the box and hiding them until you need or search for them, without costing anything.But if you really want this, just fork and maintain it yourself. That’s not asking any more of you than you’re asking of me. If you want me to maintain a flag to remove it, I can ask you to maintain a fork removing it. Telling people to “fork it” often upsets them.Very few people maintain their own patches etc. and demand entire projects to move to comfort them. It’s a very disempowering mindset to beg others to do what they could very easily do themselves, forgoing their own agency.I’ve always believed there should be way more forks, both personal and maintained ones.I do blame myself and venture-backed opensource in general here. There’s a whole generation which expects highly polished, funded, opinionated projects with websites and paid support staff (in Discord, Slack etc.) believing an open sourced project is a product - and it was a product in these venture backed cases. But that’s such a minute part of the ecosystem.Open source includes sharing, but it’s about freedoms and rights. That’s the core part of open source, defining OSI-approved open source licenses. Use the software as you want, modify and fork it. None of those rights are about stability or obligation to maintain. People blame maintainers for shipping security vulnerabilities, but why didn’t you review that commit?