Cameron McKay Claude Code is fantastic when you’re sitting at the computer it’s running on. You hand it a task, watch it work, course-correct when it goes sideways. The trouble starts when you want it to keep going while you’re out, asleep, or otherwise away from the keyboard.
One approach is to stop your machine from sleeping in the first place. macOS has caffeinate, and Linux has half a dozen ways to inhibit suspend. That works for short jobs, but it ties up your main machine and burns your battery if you’re on a laptop.
A nicer approach is to give Claude Code its own box. A spare Mac Mini, a NUC tucked into a closet, even a Raspberry Pi will do. You just need something that’s always on and doesn’t care if you wander off. Since Claude Code is a CLI, you SSH in from wherever you are and use it like any other terminal app. It works great. Right up until the moment your SSH connection drops, which it inevitably will, because that’s what SSH connections do. When the connection goes, Claude Code goes with it, and whatever it was halfway through doing is gone.
This problem gets especially fun if you’re driving Claude Code from your phone over a client like Termius, where a flaky cellular connection or a screen lock can cut you off in the middle of an interesting tool call.
In this article, I will compare four ways to keep Claude Code running across SSH disconnects (screen, tmux, dtach, and zellij) and explain why I ended up on zellij specifically for Claude Code work.
Why nohup and disown don’t help
The first thing you might reach for is nohup claude or claude & disown. Both of these protect a background process from SIGHUP, which sounds like exactly what we want.
It doesn’t work for Claude Code. Claude Code is an interactive TUI. It needs a real terminal attached to it to render its UI, capture your keypresses, and stream responses. nohup will keep the process alive but disconnect its stdin/stdout, leaving you with a zombie you can’t reattach to. The actual fix is a terminal multiplexer: a program that owns the real terminal, runs Claude Code inside it, and lets you detach and reattach the multiplexer’s terminal at will.
What we actually want from a multiplexer
For Claude Code specifically, there are three requirements:
- Survives disconnects. The multiplexer keeps Claude Code running after our SSH session dies. All four tools do this.
- Replays terminal scrollback when we reattach. Claude Code persists its own conversation history independently, so this is not about losing data. It is about the rendered view: a multiplexer with no terminal scrollback shows you only whatever the TUI happens to be drawing the moment you reconnect. We want to be able to scroll back through what happened just as if we had been watching the whole time.
- Doesn’t have a weirdass config file, a custom terminal emulator, or arcane incantations you have to Google every time you use it. A multiplexer is a tool you reach for constantly, and one that demands a chapter of upfront learning every time it touches your fingers is not the right tool for the job.
Requirements two and three together are what separate the four tools.
screen
screen is the original. It dates to 1987 and has been quietly available in every package manager you’ll meet for decades. You start it with screen, run Claude Code inside it, hit Ctrl+A d to detach, and screen -r to reattach later.
Scrollback works, but you have to enter “copy mode” with Ctrl+A [ to scroll, then Esc or q to exit. Mouse scroll requires config tweaks. The default keybindings are awkward by modern standards, and the UX feels every bit of its 39 years.
It works. I would not recommend it in 2026 unless you’re on a system where you genuinely cannot install anything else.
tmux
tmux is screen’s modern successor and the default choice for most people. It’s actively maintained, has a sane plugin ecosystem, and supports panes and tabs.
Same scrollback story as screen, though: you enter copy mode with Ctrl+B [, scroll, then q to exit. Mouse scroll works once you put set -g mouse on in your .tmux.conf, but even then it interacts oddly with full-screen TUI apps. The whole “prefix key then another key” model takes getting used to, and the config syntax is its own little language.
It’s solid, but the scrollback ergonomics are still a friction point for the Claude Code use case. You don’t want to enter copy mode every time you reattach just to read what Claude did.
dtach
dtach goes the opposite direction: minimalist. It’s a single tiny binary whose only job is to detach and reattach a process. No panes, no tabs, no config, no scrollback. You start it with dtach -A /tmp/cc.sock claude, hit Ctrl+\ to detach, and dtach -a /tmp/cc.sock to reattach.
I tried dtach first, and it didn’t last long. It’s the most minimal of the four (a single tiny binary, no config, just a Unix domain socket file you point at to reattach) and that minimalism is genuinely appealing. The reason it didn’t stick is that there is no scrollback buffer at all. Claude Code itself persists the conversation, so you don’t actually lose anything, but when you reattach you only see whatever the TUI is currently rendering. Anything that scrolled past while you were gone (streaming output, progress indicators, partial tool calls) is just gone from the visible window.
For Claude Code specifically, this is an ergonomic problem rather than a data problem. You want to come back and visually re-walk what happened, the same way you would if you had been watching the whole time. dtach cannot do that, and after a few weeks of squinting at the current screen and wishing I could scroll up, I went looking for something with a real terminal buffer.
zellij
zellij is a Rust-based multiplexer with opinionated, modern defaults. Mouse scroll works out of the box. Keybindings are discoverable, with a hint bar at the bottom of the screen showing you what each modifier does. The config is in KDL instead of a custom DSL.
The killer feature for Claude Code: on reattach, you get the full scrollback buffer, scrollable with the mouse wheel, no copy mode, no mode switching. Whatever Claude did while you were away, it’s all right there.
It is heavier than dtach (a Rust binary with a real runtime), and it occasionally intercepts keybindings that conflict with TUI apps. But for the Claude Code use case it is the only one of the four that gets reattachment right by default.
Comparison
| Survives disconnect | Scrollback on reattach | Mouse scroll | Sane defaults | |
|---|---|---|---|---|
| screen | yes | copy mode (Ctrl+A [) | needs config | no |
| tmux | yes | copy mode (Ctrl+B [) | needs config | no |
| dtach | yes | none | yes (terminal-native) | yes (nothing to configure) |
| zellij | yes | just works | yes | yes |
A bonus: jumping out for CLI work
While Claude Code is running in the main pane, Ctrl+P n opens a new shell pane right next to it. Run git status, tail a log, poke around the filesystem. Claude Code keeps running in the original pane, oblivious. Ctrl+P x closes the new pane when you’re done. Same model with tabs via Ctrl+T n if you’d rather have full-screen separation.
Verdict
Just use zellij, unless you already live inside screen or tmux and have your config dialed in. In that case, stick with what you know. For everyone else, especially anyone coming to terminal multiplexers fresh, screen and tmux are arcane enough that the learning curve isn’t worth it. zellij gives you scrollback for free and zero config to memorize, which are the two things that actually matter for an asynchronous agent you walk away from.