Interview With Mitchell Hashimoto<br>Jul 2026 - Alex AlejandreMitchell Hashimoto was behind Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint and now builds Ghostty and Vouch.<br>In this interview, we talk about terminals, Zig and open source.<br>You&rsquo;ve been interviewed a lot. Why do people like to interview you?<br>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&rsquo;s different here is there&rsquo;s no known agenda coming into it; neither of us have anything to sell.<br>What do you find so fun about terminals? Like, why Ghostty?<br>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&rsquo;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&rsquo;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.<br>After 15 years building CLIs, I didn&rsquo;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&rsquo; group chat which got repurposed. I didn&rsquo;t want to publish because my public persona would generate too much undue attention, so I ran a private beta for a long time.<br>How can we push terminals harder?<br>I don&rsquo;t support pushing terminals to the extreme. Sure, they&rsquo;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&mldr; You could.<br>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&rsquo;s a lot of opportunity in the ecosystem here and I&rsquo;d love to build more protocols to enable that.<br>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.<br>I want to make the terminal a special place for applications. The PTY&rsquo;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.<br>What do you think about non-legacy terminal APIs?<br>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&rsquo;s the DOM and JS APIs. On Apple, it&rsquo;s AppKit, Cocoa and SwiftUI. On Windows, it&rsquo;s Win32, WinUI etc. On Linux, it&rsquo;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&rsquo;ve landed on. There&rsquo;s no reason for us to build something based on our own understanding without researching decades of prior art. That&rsquo;s the approach I&rsquo;m trying to take here. I&rsquo;ve not introduced any custom protocols yet.<br>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...