Michael Zazon

Knowledge & tools · Build log

Terminal setup: tmux, Ghostty and the 1Password CLI

I run the same tmux on every machine with a fast terminal and pull secrets from 1Password only when something needs them.

2 min read

I want the same tmux on every machine so muscle memory carries over, a terminal that’s fast, and secrets kept out of my dotfiles.

My tmux configuration is a single template in my chezmoi repo. Every machine has identical bindings and history after applying the configuration. The only per-host difference is the tmux status bar color: my laptop is blue, my home server is teal, and the always-on Mac is purple. I can glance at the bottom of the window and know which machine I’m on before running commands.

Ghostty over SSH or mosh to tmux, Claude Code sessions, and op fetching tokens Ghostty on the laptop SSH or mosh tmux, same config one color per machine Claude Code sessions 1Password op token per call

I’ve been running both Ghostty and iTerm2. The first problem I had with Ghostty was with SSH. My sessions to servers broke because they complained about unsuitable terminal: xterm-ghostty and echoed everything I typed in the shell. This was because Ghostty reports its own terminal type, but servers that don’t know about it won’t have a terminfo entry for it.

Ghostty’s terminfo page offers two solutions: either install the Ghostty terminfo on every server you connect to, or configure Ghostty to report a terminal type that all servers know about. I decided I didn’t need Ghostty’s own terminal type on the servers I was connecting to (which I was mostly reaching via tmux anyway), so I went with option 2. I lost a few Ghostty-only extras (styled underlines, extended key reporting), but I rarely need those in my day-to-day work. One line in my Ghostty config:

term = xterm-256color

The bigger round of tmux changes came from a research doc on Claude Code terminal configuration I’d compiled the day before. The agent checked my config against the doc point by point, read me the gaps it found, and I approved every change (“we can always revert”). Two mattered most: extended keys so Shift+Enter gets through to Claude Code (the rest of that setup: My Claude Code setup one chezmoi source for every machine), and a much longer scrollback history.

That same day, I added the tmux-resurrect and tmux-continuum plugins to restore sessions, so my Claude Code sessions would come back after a restart. But Continuum’s auto-restore restarted the saved claude processes without attaching a terminal, and every subsequent SSH attempt to attach failed with open terminal failed: not a terminal. Turns out restoring a shell is easy, but Claude Code needs an actual terminal at startup.. something I hadn’t considered when picking plugins. I had the plugins removed, and tmux has been running without them since.

1Password only pulls a token when something needs it. The agent that calls the API runs the 1Password CLI op command to read the token at the time it’s needed. Nothing is stored in a dotfile. The service account the agent layer uses only has access to a single vault. I handle secrets for services running on the home server differently, as I wrote about in 1Password CLI and Connect secrets without env files.

I’m exploring using 1Password environment files and the new 1Password agent integration in my workflows, but so far this scoped down vault access with op CLI has been extremely useful for secrets management in my agent layer.

With tmux mouse mode on, Shift-drag in Ghostty gets normal text selection back. I like the speed and limitless config-ability and customizations Ghostty offers. I’ll be sticking with it for now.