tmux plugins: TPM, and the six worth installing

TPM (Tmux Plugin Manager) is how you install tmux plugins: clone it once, list plugins as set -g @plugin lines in ~/.tmux.conf, then press prefix and a capital I to fetch them. Most tmux setups only need three or four plugins — session persistence and pane/vim navigation cover almost everything people actually reach for. None of this changes the actual tmux commands covered in tmux commands; plugins add bindings on top, they don't replace what's already there, and every one of them is ultimately just writing the options and bindings documented in the tmux man page on your behalf. If tmux isn't installed yet, start at installing tmux — TPM needs a working tmux and git, nothing else.

Installing TPM#

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
 
run '~/.tmux/plugins/tpm/tpm'

The plugins worth installing#

Session persistence: resurrect and continuum#

These are two separate plugins that are almost always installed together, and it's worth being precise about which one does what. tmux-resurrect is the save/restore mechanism — prefix Ctrl-s writes the current state to disk, prefix Ctrl-r reads it back. On its own it's a manual snapshot, not automatic.

tmux-continuum sits on top of it: it calls resurrect's save on a timer, and can call its restore automatically the moment tmux starts.

set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '15'

One caveat worth knowing before you rely on this: continuum restores state once a tmux server exists, it doesn't itself get tmux running again after a reboot. If your goal is "reboot the box and the session is just there," you still need something outside tmux — a systemd unit or a cron @reboot line — to start tmux in the first place. Continuum's own docs cover that wiring; don't assume it happens for free.

Staying oriented: vim-tmux-navigator and tmux-yank#

vim-tmux-navigator is the one people install after they've spent a week hitting prefix then an arrow key to move out of vim and into the next pane, and getting tired of it. The full config — both the tmux side and the vim/Neovim side — is in tmux and vim, since it needs changes in both places to work.

tmux-yank is smaller in scope but removes a real annoyance: without it, a copy-mode selection only lands in tmux's own paste buffer, and getting it to the system clipboard means piping through pbcopy or xclip by hand in your config. tmux-yank does that detection for you.

A floating scratch pane: tmux-floax#

tmux-floax is the odd one out on this list because it doesn't change how existing panes behave — it adds a new kind of pane. Toggling it opens a floating, centred pane on top of your current layout rather than splitting it, so your windows keep their sizes and the thing you popped up disappears again when you toggle it off. It's the right shape for a quick git status, a one-off curl, or a shell you need for thirty seconds and don't want to rearrange your layout for. Its README requires tmux 3.3 or newer.

Install it like anything else in the list:

set -g @plugin 'omerxx/tmux-floax'

The README documents the default binding as prefix p to toggle the floating pane, and prefix P (shifted) for the plugin's own menu. Size, colours and the title are options rather than edits — @floax-width and @floax-height both default to 80%, and @floax-session-name defaults to scratch, which is a real, separate session behind the popup rather than a pane in your current window (see tmux new session for what that distinction actually means).

When is a normal split better? Whenever you need to watch two things at once. A floating pane covers whatever is underneath it, which is exactly what you want for a transient command and exactly wrong for a test watcher, a log tail, or a dev server you want in the corner of your eye while you edit. Popups are also not where long work belongs: the point of the plugin is that you dismiss it. If you find yourself toggling the same floating pane back open all day, that's a split — or a window — asking to exist.

One status-bar theme, if you want one#

Plenty of tmux status-bar plugins exist, and most of them are cosmetic — the actual value is in the plugins above, not in the status line. If you want a themed status bar, catppuccin/tmux is a current, actively maintained option worth looking at rather than something abandoned since 2019. Treat this one as taste, not signal.

Most people need three plugins, not thirty#

Dotfiles repos with forty-line plugin lists are usually the result of years of "I'll try this" commits that never got removed, not a considered setup. A reasonable core is TPM itself plus tmux-sensible, tmux-resurrect and tmux-continuum, and vim-tmux-navigator if you use vim or Neovim. Add tmux-yank if you copy out of tmux often. Add floax if you keep wanting a scratch shell that doesn't disturb your layout. Add a status theme if you care what it looks like. Stop there — every additional plugin is something you now have to remember exists when something behaves oddly.

Plugins are why tmux feels slow to start#

If tmux takes a visible moment to draw its first prompt, plugins are almost always the cause, not tmux itself. TPM's run line, and any run-shell hook a plugin registers, execute every time the first client attaches — each one is a process fork, and they add up linearly with plugin count. Status-bar segments that shell out on every refresh (battery, CPU, weather-style plugins) cause a second, separate kind of lag: redraw stutter rather than startup delay, but it reads the same to the person hitting it.

To find the culprit, comment plugins out of ~/.tmux.conf one at a time and reload, or start a throwaway session with a stripped config (tmux -f /dev/null) to confirm a plugin-free tmux is instant — if it is, the slowdown is in the list, not in tmux.

Once tmux-continuum is actually keeping a session alive across reboots, the next question is usually whether it worked — and checking that from somewhere that isn't the machine itself is the same problem tmux ssh covers for connections in general, and tmux in the browser covers for everything that isn't a terminal. If you'd rather glance at a session from a browser than reattach over SSH to confirm, that's what mtmux (npm i -g mtmux) does — what it is, and the reference docs for how sessions show up on the other end. It doesn't page you when something finishes; you open the session and look.