Claude Code tmux: Keep a Session Alive After SSH Drops

The Claude Code chat on my Raspberry Pi 5 is still there when I close my laptop. It has been up since Oct 26 through 33 logged SSH disconnects.

heads up on one thing: I haven’t tested a hard network cut, only the normal ways of leaving. That section is near the bottom.

The short version

Start Claude inside a detached tmux session, and SSH becomes a window you look through. This is the 10-line script I used before I automated it:

#!/usr/bin/env bash
# claude-tmux NAME [MODEL]  — start a detached tmux session running Claude Code.
#   claude-tmux opus opus
#   claude-tmux sonnet sonnet
#   claude-tmux            -> session "claude", default model (same as before)
# Attach: tmux attach -t NAME     Detach: Ctrl-b then d
name="${1:-claude}"
model="${2:-}"
cmd="${CLAUDE_TMUX_CMD:-/home/benp/.local/bin/claude}"
[ -n "$model" ] && cmd="$cmd --model $model"
cmd="$cmd --remote-control"
if tmux has-session -t "$name" 2>/dev/null; then
  echo "session '$name' already running — attach with: tmux attach -t $name"
  exit 0
fi
tmux new-session -d -s "$name" -c /home/benp/raspi "$cmd" && echo "started '$name' — attach with: tmux attach -t $name"

Receipt My first launcher, 10 lines, run by hand. Its systemd wrapper was retired on 2026-10-01.

Swap /home/benp for your own home directory, in both places. The -c path is the folder Claude starts in.

Run claude-tmux, then tmux attach -t claude. Detach with Ctrl-b then d. Close the laptop, and the session keeps running. tmux attach picks it back up from any machine.

Why a dropped SSH session doesn’t kill it

The tmux server is its own process, and Claude is a child of the tmux server, not of your SSH login. When SSH ends, only the login ends.

On my Pi it goes one step further. The tmux server is started by a systemd user service, not by a login at all. So there is no login to lose.

The part tmux alone doesn’t cover

A reboot or a power cut takes tmux down with everything else. To get the chats back on their own, I run a small watcher as a systemd user service:

[Unit]
Description=Always-on Claude chats (Remote Control), resumed into their existing conversations
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/bin/sleep 15
ExecStart=/bin/bash /home/benp/raspi/scripts/agents-keepalive.sh
Restart=always
RestartSec=10
# Stopping or restarting this watcher must never take the chats down with it.
KillMode=process

[Install]
WantedBy=default.target

Receipt The tmux session this feeds has been up since Oct 26 through 33 logged SSH disconnects. The unit itself has been active since Oct 28.

Two things in there matter more than the rest.

KillMode=process is what lets me restart the watcher without killing the chats. systemd’s default kills every process in the service’s group.

User services only start at boot if linger is on for your account. On mine it is. For yours: loginctl enable-linger $USER.

agents-keepalive.sh is about 300 lines, most of it other chores (context-size nudges, a daily pulse), so I’m not pasting it. The core is small. Every 60 seconds it reads a text file with one chat per line (a name and a session id). For any chat not running, it opens a tmux window and runs:

claude --resume <session-id> --remote-control <name>

The script’s own header says that after a reboot, a power cut or a crash the chat comes back on the same claude.ai link with its history. I haven’t rebooted the Pi to check that claim for this post.

Boot→systemd user service→keepalive, every 60s→tmux window per chat→claude —resume —remote-control

Two guards in the script:

A chat that dies within two minutes of starting, three times in a row, is left down and logged. A bad session id can’t respawn forever.
If a pane shows “Remote Control disconnected”, it types /remote-control into the chat, once every ten minutes at most. That’s the fix for a link that dropped during a roughly 30-minute network outage and never came back by itself.

What it costs

Two Claude sessions in tmux used about 925MB of the Pi’s RAM. The whole board sat at 1.3GB used with 2.6GB free. The numbers are from the setup post, and the memory behaviour over weeks is in the three-week follow-up.

What I haven’t tested

33SSH disconnects logged since Oct 26

2of them I actually read

0hard network cuts I know of

The journal shows 33 “Disconnected from user” lines from sshd since Oct 26 and no timeout, connection reset or broken pipe lines. I read two of them. Both were “disconnected by user”, so a clean exit. The tmux session was created Oct 26 at 01:56 and has stayed up through all 33.

That proves clean exits are safe. It doesn’t prove a pulled network cable or a laptop falling asleep mid-command is, and I can’t tell you whether any of the 33 had a terminal attached to the chat at the time. I expect a hard cut to be fine, since nothing in the chain depends on the SSH connection. Expect isn’t tested. If you run the cut test before I do, I’d like to hear what happened.

Anthropic documents Remote Control separately, in Continue local sessions from any device with Remote Control. I haven’t tested whether a Remote Control session on its own survives the terminal closing, so I’m not making that claim here.

Versions, so you can compare: Claude Code 2.1.312, tmux 3.5a, Raspberry Pi 5 Model B on Debian 13 (trixie).

happy to answer questions.

Sources

Anthropic, Continue local sessions from any device with Remote Control (Claude Code docs, read 2026-10-30 for the title only).
The launcher, unit file and counts are from my own Pi, read 2026-10-30: claude-agents.service, agents-keepalive.sh, claude-tmux and the system journal since 2026-10-26.

Ben Peetermans

I build MVPs and run ad campaigns with AI, and I write these notes from real projects. Twenty years shipping for the web. If you want someone who works with these tools every day to build yours, that is what I do.

Work with me See the work