How to Use screen as a Session-Persistence Tool

GNU screen predates tmux as a terminal session multiplexer, and while tmux has largely superseded it in general popularity, screen remains genuinely useful — particularly on older or more minimal systems where it’s already installed and tmux isn’t.

Step 1: check whether screen is already installed

screen --version

Screen ships pre-installed on many Unix-like systems by default, unlike tmux, which is a more common reason to reach for it specifically — no installation step needed if it’s already present.

Step 2: install screen if needed

sudo apt install screen     # Debian/Ubuntu
brew install screen         # macOS
pkg install screen          # FreeBSD

Step 3: start a new named session

screen -S work

Step 4: understand screen’s prefix key

Ctrl-a   (screen's default prefix, distinct from
          tmux's default Ctrl-b)

Screen’s default prefix key is the historical origin of the “remap tmux’s prefix to Ctrl-a” convention many tmux users adopt — for users switching between both tools, keeping them consistent avoids relearning muscle memory.

Step 5: detach from a session

Ctrl-a then d

Exactly like tmux, detaching leaves the session and everything running inside it alive in the background.

Step 6: reattach to a running session

screen -r work

If a screen session was left in an “attached” state due to an unclean disconnect (a dropped SSH connection, for instance), force reattachment with:

screen -d -r work

Step 7: list currently running sessions

screen -ls

Step 8: create multiple windows within one session

Ctrl-a then c    (create a new window)
Ctrl-a then n    (next window)
Ctrl-a then p    (previous window)

Screen supports multiple windows within a session similarly to tmux, though its default pane-splitting support (Ctrl-a then S for a horizontal split, | for vertical) is less commonly used and less refined than tmux’s equivalent.

Step 9: know screen’s genuine limitations relative to tmux

Screen’s scripting and configuration capabilities, and its pane management specifically, are generally considered less capable than tmux’s — most users choosing between the two for a new setup, without a specific reason to prefer screen, tend toward tmux; screen’s continued relevance comes primarily from its wider default pre-installation and long historical track record.

Why screen still deserves a place in your toolkit despite tmux’s popularity

Encountering a remote server or minimal environment where screen is present and tmux isn’t — and where installing new software isn’t practical or permitted — is common enough that knowing screen’s basic session-persistence commands (detach, reattach, list sessions) remains genuinely useful, even if tmux is your primary choice everywhere you have a free choice between the two.

Screen’s own, considerably older origin

GNU Screen predates tmux by decades — it was originally designed by Oliver Laumann and Carsten Bormann at Technische Universität Berlin and published in 1987, addressing the exact problem this guide covers: letting a user switch between multiple tasks on a single terminal and detach from, then reattach to, long-running sessions. Laumann handed off maintenance around 1990 to Jürgen Weigert and Michael Schroeder at the University of Erlangen–Nuremberg, who brought the project under the GNU umbrella and added scrollback, split-screen, and session-sharing over the following years — meaning the “screen” you’re installing today carries roughly four decades of continuous, if not always rapid, development behind it, considerably longer than tmux’s own 2007 origin.

Step 10: send commands into a running session from outside it

screen -S work -X stuff "echo hello from outside$(printf \\r)"

The -X flag sends a command to an already-running session’s internal command interpreter rather than to the shell running inside it — combined with the stuff command, which injects literal text directly into a window’s input buffer as though it had been typed there, this lets an external script drive a long-running screen session without attaching to it interactively at all. This is genuinely useful for automation that needs to interact with a persistent session — feeding a command to a long-running REPL or monitoring tool inside screen from a cron job or a separate script, for instance — though it depends on knowing exactly what the target window currently expects as input, since stuff has no awareness of the receiving program’s actual state.

Ctrl-a then :multiuser on
Ctrl-a then :acladd otherusername

Screen’s multiuser mode, enabled from inside a running session, allows a named second user to attach to and interact with the exact same session simultaneously — both users see identical terminal output and can type input, useful for pair debugging on a shared server or live training where narrating over a separate video call alongside independent terminals would be considerably more awkward. The other user attaches with screen -x (lowercase -x, distinct from the uppercase -X used to send remote commands) once added via acladd; this is a genuinely different capability from tmux’s more commonly discussed session-sharing, and one of the more specific reasons screen still gets deliberately chosen over tmux in some shared-server contexts today.

Related:

Sources: