Getting started

Macterm vs. tmux

Most people run tmux inside a terminal for two reasons: sessions that survive, and splits. Macterm does both natively, so if those are your reasons, you can stop running it.

You are not required to. tmux works fine inside a Macterm pane — it is just a program, and the terminal underneath handles it correctly.

What replaces what

tmux Macterm
session project — a directory with its own tabs, in the sidebar
window tab, listed under its project
pane pane, split from a tab
detach / tmux attach quitting and relaunching the app
.tmux.conf layout scripting a YAML project file
tmux send-keys the macterm CLI
tmux-resurrect / continuum built in — nothing to install

No prefix key

Macterm's shortcuts are ordinary macOS shortcuts, not keys a program in your terminal has to intercept, so there is nothing to press first and nothing for your editor to collide with.

A binding can also be handed back to the program when you want it: passthrough lets one chord move between nvim's own splits while you are inside nvim, and between Macterm's panes when you reach the edge.

Persistence works differently

tmux keeps shells alive by being a server your terminal attaches to. Macterm does the same with zmx, one session per pane — but you never address it directly. Quitting detaches; launching reattaches.

Two consequences worth knowing:

Over SSH, it is inverted

The usual remote workflow is ssh host, then tmux attach on the far side. A remote project points Macterm at host:~/dev/api instead, and every pane in it is a persistent session on the host, reattached automatically.

Because the host owns the session, those panes survive quitting, a dropped connection, and rebooting your Mac. There is no tmux attach to type.

What tmux still does better