Ghostty terminal on a Mac: what changes once the window keeps up

Most people who look up the ghostty terminal already have a working setup. There is a shell with a prompt that took a weekend to get right, a multiplexer, a font with ligatures, and a theme that matches the editor. The question is not whether a new terminal emulator can render text. It is whether swapping the window is worth an afternoon, and what specifically gets better. The honest answer has a narrow shape: Ghostty changes how the window behaves as a macOS application, it removes a pile of configuration that other emulators require, and it does nothing at all about the part of the day spent moving between a file window, a terminal, and a chat panel.

What Ghostty is, and what it is not

Ghostty is a terminal emulator with a shared core written in Zig and a separate native front end for each platform. On macOS the interface is Swift, using AppKit and SwiftUI. On Linux it is Zig against the GTK4 C API. The project is MIT licensed and was started by Mitchell Hashimoto. Version 1.3.1 shipped on March 13, 2026, following 1.3.0 four days earlier.

The project's own framing is that terminal emulators usually make a person pick two of three things: speed, features, or a native interface. Ghostty aims to be competitive in all three rather than best in any one. That is a more modest claim than the coverage around it suggests, and it is the right claim to evaluate against.

What "native" means here is concrete rather than decorative. Tabs and splits are real macOS components, not characters drawn into a text grid. Window state is restored on restart through the system mechanism. Quick Look works on selected text with a three finger tap or force touch. Secure keyboard entry activates at password prompts, with a lock icon in the corner while it is on. There is an AppleScript dictionary for driving windows, tabs, layouts, and input events. Rendering goes through Metal on macOS and OpenGL on Linux.

Feature support for the programs running inside the window is the other half. Ghostty implements the Kitty graphics protocol, the Kitty keyboard protocol, synchronized rendering, hyperlinks, and light and dark mode notifications. Those exist for the benefit of editors and multiplexers rather than for direct use, which is why the difference shows up as Neovim or Zellij being able to do something it could not do before, rather than as a visible feature in a menu. Grapheme clustering is handled properly, so multi codepoint emoji such as flags and skin tones render as one character, and individual clusters in Arabic and Hebrew render correctly, although only left to right text is laid out.

What Ghostty is not: a multiplexer replacement, a shell, a file browser, or a session manager. It draws a grid and manages windows. Anything about where files live or what the project state is stays outside it. Windows support is on the roadmap and not shipped, so a team split across macOS and Windows cannot standardise on it yet.

Installing it without disturbing an existing shell setup

The Ghostty project distributes official prebuilt binaries for macOS only. Those builds are signed and notarized by the project, which means Gatekeeper lets them through without the right click workaround. Installation is the ordinary pattern: download the disk image, open it, drag the application into the Applications folder.

The Homebrew route is a cask maintained by the community that repackages the same official disk image:

brew install --cask ghostty

Because it wraps the project's own build, the signing situation is identical. For Nix on macOS the package name is ghostty-bin, a repackaging of the disk image, which is a different thing from the ghostty package that builds the GTK application for Linux. Compiling from source under macOS is not currently possible through Nixpkgs, because the required ecosystem support, including Swift 6 and a reproducible alternative to xcodebuild, is not there yet.

Nothing in the install touches .zshrc or .zprofile. A terminal emulator launches a shell; it does not own the shell configuration. That is why trying Ghostty costs almost nothing and why keeping it alongside the built in Terminal for a week is a reasonable way to decide.

The configuration file, and the handful of lines worth setting

Ghostty states a zero configuration philosophy: sensible defaults, an embedded default font in JetBrains Mono, built in nerd fonts, and an explicit project goal of removing the need to configure anything beyond subjective choices like the theme. Starting with an empty configuration is a real option, not a beginner's path.

When configuration is wanted, the file is named config.ghostty, and it was simply config before version 1.2.3. It loads from the XDG path first, $XDG_CONFIG_HOME/ghostty/config.ghostty, which defaults to $HOME/.config/ghostty/ when the variable is unset. On macOS there is a second location, $HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty, and the macOS specific files load after all XDG files, so values there win on conflict.

The syntax is key = value, one per line, with # starting a comment on its own line. Keys are case sensitive and always lowercase. An empty value resets a setting to its default. A useful detail for scripting: every configuration key also works as a command line flag, so ghostty --font-family="JetBrains Mono" is equivalent to the file entry. Configuration can be split across files with config-file, which is how a shared base and a machine specific override are usually arranged.

One option worth knowing about for a multilingual desktop: language forces the interface strings to a specific language rather than following the system, it arrived in 1.3.0, it is GTK only, and it cannot be reloaded without a full restart. It also has no effect on the programs running inside the window, which keep using the system language.

The theme line is the one that pays off immediately. Ghostty ships hundreds of themes selectable with a single line, and they can switch automatically with the system light and dark mode. Past that, font-family, font-size, and a keybind or two for splits cover what most people actually change. Font names available on the machine come from ghostty +list-fonts.

Shell integration is where the practical gains sit

The rendering speed is what gets written about. The behaviour changes that get noticed on a Tuesday afternoon come from shell integration, which Ghostty injects automatically for bash, elvish, fish, nushell, and zsh.

What that injection buys:

• New terminals open in the working directory of the previously focused one, so a split starts where the work already is.
• Closing a terminal sitting at a prompt skips the confirmation dialog, because the shell has reported that nothing is running.
• Complex prompts redraw rather than reflow on resize, which is the fix for a prompt that turns into garbage when a window is dragged wider.
• Command output can be selected in one gesture: triple click while holding command on macOS.
• The jump_to_prompt binding scrolls backward and forward between prompts instead of by lines.
• Option click at a prompt moves the cursor to the click position.
• Optional wrapping of sudo to preserve the Ghostty terminfo, and of ssh to set up the remote environment. Both are off by default.

One macOS specific trap: the bash that ships at /bin/bash does not support automatic injection, so the integration script has to be sourced by hand or a current bash installed from Homebrew. Fish 4.0 and later already marks prompts itself, so prompt jumping and resizing work there without the integration. Detection is a string match on the basename of the command being run, and shell-integration = fish forces it when the shell has an unusual name. shell-integration = none turns it off.

Verification is a log line reading that shell integration was automatically injected. Seeing ghostty terminfo not found, using xterm-256color instead usually means GHOSTTY_RESOURCES_DIR is not pointing at the application bundle.

Where it differs from the terminal already on the Mac

The built in Terminal is not a weak application, and the comparison is narrower than the enthusiasm suggests.

Capability	Ghostty	Terminal (macOS)
Rendering	GPU, Metal	CPU
Splits	Native components, configurable bindings	Split pane, Command+D
Themes	Hundreds shipped, auto switch with system appearance	Profiles, edited in preferences
Ligatures	Supported, with font feature control	Not supported
Images in the grid	Kitty graphics protocol	Not supported
Automatic shell integration	bash, elvish, fish, nushell, zsh	Not provided
Configuration	Text file, also usable as CLI flags	Graphical preferences
Drop down window	Quick Terminal	Not provided
Updates	Auto update in the application	With the operating system

Two rows carry most of the practical weight. The Kitty graphics protocol is what lets a program draw an image inside the grid, which matters for anyone plotting or previewing without switching windows. The Quick Terminal is a lightweight window that animates down from under the menu bar, which turns a shell into something that appears over the current work instead of requiring a switch to another application.

The rest is preference. Anyone who is happy in Terminal and does not use ligatures, images, or splits will find the difference small.

What a faster window does not fix

Here the search term and the actual problem tend to separate. A terminal emulator addresses the terminal. It does not address the arrangement of windows around it.

The daily pattern for most people working on a Mac with files and a command line and a model in a chat panel is three applications and a lot of switching. A folder is open in one window to see what is there. A shell is open in another to act on it. A third window holds the assistant that gets a directory listing pasted into it. Replacing the second window with a faster one leaves the switching untouched.

That is not a criticism of Ghostty, which is explicit about its scope. It is a reason to be precise about what a change is expected to deliver. If the complaint is a sluggish window, a tearing scroll, or a prompt that breaks on resize, a new emulator is the right fix and the afternoon is well spent. If the complaint is that context has to be carried by hand between a file window and a shell and a chat panel, no emulator changes that, because the emulator never knew which folder was being looked at.

Tools that put a directory listing, a shell, and a model in one window attack the second problem and are worse at the first, since none of them match a dedicated emulator on rendering. Treating the two as separate purchases keeps the decision clear. A comparison of file managers is the place to work out which of the two problems is actually the expensive one, and what a combined window covers sets the boundary of what that approach replaces.

What to change first

Install Ghostty, run it with no configuration for a week, and pay attention only to whether splits opening in the right directory and prompts surviving a resize change how the day goes. Then set a theme and a font, and nothing else. If the week shows that the friction was never the window but the trip between the folder, the shell, and the assistant, that is a different tool and a different decision, and Atriens is built for that second case.