Developer Productivity

Terminal sessions that survive a laptop reboot

How to configure tmux with tmux-resurrect and tmux-continuum to automatically save and restore session state across reboots and crashes.

Mohammed Saqib10 min read
Futuristic digital interface displayed on laptop screen with neon red keyboard.
Photo by Rafael Minguet Delgado on Pexels · Pexels License

Your laptop crashes during a demo. You reboot, open a terminal, and the carefully arranged tmux session with five windows—each in a specific directory, running a dev server, a log tail, and a vim buffer—is gone. That’s because tmux, by default, stores its session state in /tmp, which the operating system wipes on every restart. The multiplexer is designed to be ephemeral: no leftover processes, no stale sockets, and a clean slate after a reboot. But for anyone who lives in the terminal, losing that context is a productivity hit that can take ten minutes to reconstruct. Fortunately, two plugins—tmux-resurrect and tmux-continuum—turn tmux into a persistent environment that survives reboots, crashes, and even intentional shutdowns.

Why tmux sessions vanish on reboot

tmux stores its server socket and session metadata in a directory under /tmp, typically /tmp/tmux-<UID>. This is a deliberate design choice: Unix conventions dictate that /tmp is cleared at boot (or periodically by tmpwatch), which prevents orphaned sockets and ensures that no process holds onto stale IPC resources after a crash. You can see the current socket path by running:

tmux display-message -p "#{socket_path}"

The output will be something like /tmp/tmux-1000/default. Because the entire directory tree under /tmp/tmux-<UID> is volatile, a reboot destroys every session, window, and pane layout that tmux was managing. This is fine if you treat tmux as a disposable session manager, but it’s a liability when you rely on it for day-to-day development.

The security angle is also relevant: a predictable socket path under /tmp could be attacked by another local user if permissions are misconfigured. The ephemeral nature mitigates that risk—there’s no persistent socket file to hijack after a reboot. But for a single-user workstation, the trade‑off is unnecessary pain.

tmux-resurrect: manual save and restore

tmux-resurrect is the foundational plugin for persistence. It saves the complete state of your tmux session—windows, panes, layouts, working directories, and environment variables—to a file in ~/.tmux/resurrect/. Installation is straightforward if you use the Tmux Plugin Manager (TPM):

# Add to ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
 
# Then run: prefix + I (capital i) to install

Once loaded, the default keybindings are:

  • prefix + Ctrl-s — save the current session state.
  • prefix + Ctrl-r — restore from the most recent save.

What gets saved is intentionally broad: every pane’s current working directory, the pane layout (including split ratios and size), the window order, and the environment variables that were set inside each pane. This means that after a restore, you’re dropped back into the exact directories you were working in, with the same shell environment. The save file is a plain text script that tmux-resurrect sources on restore, so it’s also inspectable and debuggable.

The plugin does not save pane scrollback contents by default (more on that later), and it does not attempt to resume running programs like vim or SSH connections. It saves the shell process that launched those programs, so when you restore, you get a new shell in the same directory—but the program itself is gone.

tmux-continuum: automatic saves and boot restoration

tmux-continuum layers automation on top of tmux-resurrect. It adds two key features:

  1. Periodic automatic saves — by default every 15 minutes, configurable with @continuum-save-interval.
  2. Restore on tmux start — when the tmux server starts, continuum can automatically load the last saved session.

The restore-on-start behaviour is the most useful for surviving a reboot. You configure it with a single option:

set -g @continuum-restore 'on'

With this set, continuum hooks into tmux’s server start event. When you open a terminal after a reboot (which starts the tmux server), continuum detects that no sessions exist and runs tmux-resurrect’s restore routine automatically. The full .tmux.conf snippet looks like:

set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
 
set -g @continuum-restore 'on'
set -g @continuum-save-interval '10'  # Optional: save every 10 minutes

The save interval also controls how often continuum writes a snapshot. If you’re worried about losing work between saves, you can lower it to 5 minutes, but be aware that frequent saves can cause a brief tmux freeze on large sessions.

tmux-resurrect vs tmux-continuum vs screen vs manual scripts

The ecosystem of terminal persistence tools is small but varied. Here’s how the options compare:

Feature tmux-resurrect tmux-continuum GNU Screen Manual scripts
Save/restore windows, panes, layout Yes Yes (via resurrect) No (windows only, no layout) Possible but fragile
Automatic periodic saves No Yes No You can cron a script
Restore on server start Manual Yes No You’d need to run a script at login
Resume running programs (vim, ssh) No No No No
Save pane scrollback Optional (plugin) Optional No No
Dependency on tmux version Yes Yes (same as resurrect) No No
Learning curve Low Low Low High

GNU Screen has a -r flag to reattach, but it does not save the layout of panes (Screen uses a different model with regions, not a tree of panes). Manual scripts that dump tmux list-sessions and then re‑run commands are fragile: they can’t capture the exact split proportions, working directories of every pane, or environment variables. You’d essentially be recreating the session from scratch with a shell loop.

For most developers, the combination of tmux-resurrect and tmux-continuum is the sweet spot: minimal configuration, zero‑thought restoration, and no external dependencies beyond the plugins themselves.

What gets restored and what doesn’t

It’s important to set expectations. tmux-resurrect restores the structure of your session, but not the state of the programs inside the panes.

Restored:

  • Window and pane count, positions, and sizes.
  • Each pane’s current working directory.
  • Environment variables that were set in the pane.
  • The shell history of the pane is not restored, but your shell’s own history file (e.g., .bash_history) persists across reboots anyway.

Not restored:

  • Pane scrollback (the buffer of text you can scroll back to). By default, tmux-resurrect does not save this. You can enable it with set -g @resurrect-capture-pane-contents 'on', but this serialises the entire scrollback buffer for every pane, which can multiply save time by 10x or more on sessions with many panes.
  • Running programs. When you restore, tmux starts a new shell in each pane. If you had vim open, you get a new shell—not vim at the same file and cursor position. Similarly, an SSH session becomes a local shell. To restore vim state, you need a plugin like vim-session or vim-obsession (which works with tmux-resurrect). For SSH, consider using mosh, which persists the connection across network changes, but it still won’t survive a local reboot.
  • Environment variables that were exported after the pane was created. tmux-resurrect captures the environment at the time the pane was created, not later modifications.

If you rely heavily on scrollback for debugging, you may want to enable pane content capture, but test the performance impact on your typical session size first.

Failure modes and gotchas

The plugins are stable, but they have sharp edges.

Version mismatch after a tmux update. tmux-resurrect and continuum use internal tmux commands that can change between releases. After updating tmux, you may see errors like unknown option: @resurrect-save. The fix is to update the plugins (via TPM: prefix + U). If you’re on a very new tmux (e.g., 3.4+), check the plugin repository for a compatible branch.

Large sessions slow down save/restore. A session with 20 panes, each in a deep directory tree, can take several seconds to save. The restore is faster, but the save can cause a noticeable pause. If you hit this, consider pruning unused windows or reducing the save interval. You can also disable automatic saves for specific sessions by setting @continuum-save-interval 0 in a session‑local option.

Stale socket files after a crash. If tmux crashes without cleaning up its socket, you may see sessions should be nested with care, unset $TMUX to force errors, or the server refuses to start. The fix is to kill the stale server and remove the socket:

tmux kill-server
rm -rf /tmp/tmux-*

Then start a new tmux session. Continuum will restore the last save automatically.

Plugin ordering in .tmux.conf. The set -g @plugin lines must come before the run '~/.tmux/plugins/tpm/tpm' line if you use TPM. If they appear after, the plugins won’t be loaded.

Systemd user service for guaranteed startup

Even with continuum set to restore on start, you still need to launch a tmux server after reboot. If you open a terminal manually and run tmux, that works—but if you want the restore to happen automatically as soon as you log in (or even before you open a terminal), you can use a systemd user service.

Create ~/.config/systemd/user/tmux.service:

[Unit]
Description=tmux server with continuum restore
After=network.target
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/tmux new-session -d -s boot
ExecStop=/usr/bin/tmux kill-server
 
[Install]
WantedBy=default.target

Then enable it:

systemctl --user enable tmux.service
systemctl --user start tmux.service

This starts a dummy session named boot in the background. Because continuum is configured to restore on server start, it will load your last saved session immediately. The dummy session is then replaced by the restored one (continuum’s restore creates the real windows and panes). The service also ensures that tmux is killed when you log out, which is clean.

One caveat: if you use a display manager that doesn’t run systemd user services (e.g., some lightweight WMs), you may need to start the service via a .xinitrc or a desktop entry. For most modern Linux distros with systemd, this works out of the box.

This approach is especially useful if you rely on tmux for long-running tasks that should be available immediately after login. For example, you could combine it with a dev environment that starts a web server in one pane—the server process itself won’t survive the reboot, but the pane structure and directory are restored, so you can restart the server with a single command. For setting up such a reproducible environment, see Reproducible Dev Environments with Dev Containers and a Single Script.

Key takeaways

  • tmux stores session data in /tmp by default, so reboots erase everything. Use tmux-resurrect and tmux-continuum to persist state across restarts.
  • tmux-resurrect saves windows, panes, layouts, working directories, and environment variables on demand (prefix + Ctrl-s). tmux-continuum adds automatic periodic saves and restores the last session when the tmux server starts.
  • Pane scrollback and running programs (vim, ssh) are not restored by default. Enable pane content saving only if you can tolerate the performance cost; pair with vim-session or mosh for deeper program state recovery.
  • After a tmux update, always update the plugins to avoid compatibility errors. Stale sockets can be cleaned with tmux kill-server and rm -rf /tmp/tmux-*.
  • For zero‑intervention restoration, add a systemd user service that starts a dummy tmux session on login. Continuum will then restore your last session automatically before you even open a terminal.
  • If you frequently switch between projects with different tmux configurations, consider using Use Git worktrees to review PRs without stashing your work to isolate work contexts, and pair that with separate tmux sessions for each project to keep your restore files organized.

Frequently asked questions

Does tmux-resurrect restore all programs like vim or ssh?
No, it restores the shell process that was running those programs, but the program itself does not resume its state. For vim you would need a session plugin (e.g., vim-obsession), and for SSH you might use mosh to maintain the connection across reboots.
Will it work if I use a different terminal emulator?
Yes. tmux-resurrect and continuum operate entirely within tmux, independent of the terminal emulator. The restore runs when the tmux server starts, regardless of whether you use iTerm2, GNOME Terminal, or Alacritty.
Can I restore sessions across different machines or OS versions?
It is not recommended because saved state includes absolute paths and environment variables that may not exist on the other machine. tmux-resurrect can be used across compatible systems (same OS, same directory structure) by copying the save file, but expect manual adjustments.
#tmux#terminal#productivity#workflow#linux
Share

Keep reading