Changing terminal emulators is one of those upgrades that can be either refreshingly small or unexpectedly annoying. The shell prompt still works. Vim still works. SSH still works. Yet a terminal is where a Mac developer accumulates years of small accommodations: profiles, fonts, keyboard shortcuts, window habits, copied escape sequences, and a vague fear that changing any of it will disrupt a good week.

Ghostty is a credible reason to revisit that arrangement. It is a native macOS terminal with GPU-accelerated rendering, native tabs and splits, a drop-down Quick Terminal, and a deliberately plain text configuration model. But the useful reason to switch from iTerm2 is not that a new terminal has more fashionable internals. It is that the change gives you a chance to separate the workflow you actually need from the historical settings you have been carrying around.

The migration should be boring. Keep your shell, editor, SSH configuration, and durable sessions intact. Start with Ghostty's defaults, test the few workflows that make or break your day, and only then add configuration that has a clear job.

Start by identifying what iTerm2 is really doing for you

Before importing a theme or recreating every shortcut, make a short list of the behaviors you would notice if they disappeared. For most developers, the list is smaller than their iTerm2 profile suggests:

• Open a terminal in the right repository or current working directory.
• Create a second view for logs, tests, or a local server.
• Read text comfortably for hours.
• Copy, search, and scroll through command output.
• Run Vim or Neovim, tmux, Git, and language tools without terminal weirdness.
• SSH to a remote machine without color, key, or terminfo surprises.
• Keep a lightweight scratch terminal one shortcut away.

That is the acceptance test. Features such as badges, background images, profile inheritance, triggers, and deeply customized status bars may be useful, but they are not automatically part of the workflow. If you cannot name the decision a setting supports, do not migrate it yet.

This distinction matters because iTerm2 has often become a place where shell, terminal, and session-management responsibilities blur together. A better arrangement is to let each layer do its own job:

Once those boundaries are clear, switching emulators becomes much less dramatic. You are replacing the outermost layer, not rebuilding your development environment.

Let Ghostty be plain for the first few days

Ghostty's most sensible setup step is almost no setup. Its configuration is optional and uses a simple key = value file. On macOS it can load a configuration from the XDG path or from ~/Library/Application Support/com.mitchellh.ghostty/; inspect the current default documentation with ghostty +show-config --default --docs before copying an old config snippet from the internet.

Use the default font and theme long enough to notice actual friction. Then change only the parts that materially improve readability or muscle memory:

# Example: intentionally small Ghostty configuration
font-size = 14
theme = catppuccin-mocha
window-save-state = always
split-divider-color = #4b5563

The exact values are personal. The important thing is that this file remains explainable six months later. A terminal configuration that is 20 lines long and understood is better than a 400-line imported artifact you are afraid to touch.

The next article in this series covers a maintainable macOS configuration in more detail. For this first step, resist turning a migration into an afternoon of visual customization.

Expect macOS behavior, not an iTerm2 clone

Ghostty's macOS approach is one of the practical differences. Tabs and splits use native macOS UI components, and the application follows familiar macOS conventions instead of reproducing every terminal-emulator-specific abstraction. That feels natural for many people, especially when moving between terminals, editors, browsers, and Finder windows all day.

It can also expose habits that were really iTerm2 habits. If you depend on a particular profile model, pane broadcast gesture, or window-manager treatment of tabs, test it rather than assuming the equivalent works identically. In particular, macOS tiling window managers can see Ghostty's native tabs as separate windows. That is an integration constraint worth learning before you replace your working layout automation.

Ghostty's Quick Terminal is useful precisely because it should not become your main workspace. Bind it to a convenient global shortcut and use it for a quick git status, a one-off kubectl check, or a small command you do not want to turn into a new window-management project. Keep longer work in normal windows, where it can survive context switches and remain visible in your task flow.

Validate the terminal applications that carry your day

Do not pronounce a terminal migration complete after running ls. Test the programs that exercise terminal capabilities:

# Check the terminal identity that remote programs will see.
echo "$TERM"
infocmp -x "$TERM" | head

# Exercise the application paths that matter to you.
nvim
tmux new -s ghostty-check
ssh example-host

Look for the boring failures: an editor that redraws incorrectly, an unusual keybinding that no longer arrives, a full-screen program that leaves the terminal damaged, or a remote host missing the appropriate terminfo entry. These are solvable problems, but they are easiest to solve while iTerm2 remains available as a known-good comparison.

Ghostty can automatically integrate with zsh, fish, bash, and several other shells. That integration improves prompt marking, working-directory inheritance, prompt navigation, and click behavior. It also has opt-in helpers for carrying Ghostty's terminal environment through SSH. Those are useful improvements, but do not enable remote wrapping blindly in a production workflow. First verify a few representative hosts, especially older systems and jump-host chains where terminal behavior is part of the operational contract.

If you use a nonstandard shell invocation, a nested shell, or tools such as nix-shell, remember that automatically injected shell integration may not follow you into that child shell. That is not a reason to abandon the terminal; it is a reason to know which layer owns the feature.

Preserve session durability outside the emulator

The biggest migration mistake is treating terminal windows as the durable unit of work. They are not. A macOS restart, laptop sleep, VPN reset, or accidental close will eventually prove the point.

Put remote work in tmux, screen, or a service-specific session mechanism. Keep named sessions for the work that deserves recovery, and make a fresh local terminal cheap to create. The benefit is not merely resilience: it also makes iTerm2 and Ghostty interchangeable while you migrate.

For SSH, keep identities, host aliases, jump hosts, and forwarding rules in ~/.ssh/config. Use a Different SSH Identity for One Git Repository illustrates the same principle: repository and access decisions belong in explicit configuration, not in a terminal profile that only one application understands.

That separation pays off when your work moves across a laptop, a remote host, a pair-programming session, or a future terminal emulator. The terminal should make the workflow pleasant, not become the only place it exists.

Keep the rollback path until you stop needing it

Run Ghostty beside iTerm2 for a week or two. Do not delete iTerm2 settings first. Open Ghostty for normal work, return to iTerm2 only when a real incompatibility appears, and write down what blocked you. Most of the time, the answer will be a missing keybinding, font choice, shell startup difference, or an old remote environment—not a reason to re-create every legacy feature.

Use a small migration log:

1. What task failed or felt slower?
2. Which layer owns the fix: terminal, shell, tmux, SSH, or a specific tool?
3. Is the fix durable and understandable?
4. Does it improve daily work enough to justify configuration?

That discipline keeps a terminal change proportionate. Ghostty can make a Mac development environment feel quicker, more native, and less cluttered. It cannot make a tangled shell profile, fragile remote workflow, or sprawling pane habit healthy on its own.

Switch when the defaults and a handful of intentional choices cover your real work. Then keep the emulator boring enough that your attention stays on the code, systems, and people that actually need it.

For more practical networking and engineering notes, visit Slaptijack.