The problem

Most people run their AI agent the obvious way: open a terminal in VS Code, type claude, and let it work. That's fine. The terminal stays open, the agent runs, you watch.

This post isn't about that case.

This is about the case where you already have a small machine sitting around — a Raspberry Pi in the corner, a cheap VPS, an old laptop running Linux. You SSH in. You start the agent. It begins doing its thing.

Then your laptop goes to sleep. Your VPN drops. You close the terminal by accident. Or you just want to go to bed.

And the agent dies with it.

The reason is simple: when you SSH in and run a command, that command becomes a child of your SSH session. Close the session, and the kernel sends SIGHUP to every child process. Game over.

The fix

Use tmux.

Tmux is a terminal multiplexer. Translation: it runs your shell inside a session that lives on the server, not on your laptop.

When you "detach" from tmux, the session keeps running on the server. Your SSH connection can die. Your laptop can go to sleep. The agent doesn't notice.

How it works under the hood

Tmux runs as a server process on the machine. The first time you start it, it forks a daemon that owns all your sessions, windows, and panes.

When you "attach" to a session, your terminal becomes a client of that daemon. Your keystrokes get forwarded to the shell running inside the session. The shell's output gets forwarded back to your terminal.

Detach, and the client disconnects. The daemon and the shell keep running. The agent inside has no idea anything happened — its stdin, stdout, and stderr are wired to the tmux daemon, not to your SSH session.

This is the key insight: the agent's parent process is the tmux daemon, not your shell. So when SSH dies, SIGHUP goes to your SSH shell, not to the agent.

Setup

Install tmux. On Debian/Ubuntu/Raspberry Pi OS:

sudo apt update
sudo apt install tmux

On Fedora/RHEL:

sudo dnf install tmux

On macOS:

brew install tmux

That's the entire setup. No config file required to get started.

The three commands you actually need

# Start a new named session
tmux new -s ai

# Detach from it (agent keeps running)
Ctrl+b  then  d

# Reattach later from anywhere
tmux attach -t ai

A few more that come in handy:

# List running sessions
tmux ls

# Kill a session you don't need anymore
tmux kill-session -t ai

# Attach to the most recent session
tmux a

Ctrl+b is the default prefix key. Every tmux command starts with it. Press Ctrl+b then d to detach. Press Ctrl+b then ? to see every binding.

A typical workflow

# From your laptop
ssh pi@raspberrypi.local

# On the Pi
tmux new -s ai
claude-code   # or whatever agent you're running

# Agent starts working. You press Ctrl+b then d.
# You're back at the Pi's regular shell.

exit          # close SSH. Laptop can sleep.

Next morning:

ssh pi@raspberrypi.local
tmux attach -t ai
# You're back inside the running agent. Output and all.

Why this matters for AI workloads

AI agents are rarely fast.

They:

• run long loops
• wait on API calls
• process large inputs
• crash if interrupted mid-task
• sometimes burn real money per token

A dropped SSH session means a lost run. Sometimes a lost dataset. Sometimes a half-finished refactor across 40 files.

Tmux removes the laptop from the equation entirely.

Limitations and gotchas

Tmux is not persistent across reboots. If the server reboots, every session is gone. If you need that, look at tmux-resurrect and tmux-continuum, or run your agent under systemd instead.

Scrollback is finite. The default history is 2000 lines per pane. For a chatty agent, that's nothing. Add this to ~/.tmux.conf:

set -g history-limit 100000

Copy-paste is its own thing. Inside tmux, Ctrl+b [ enters copy mode. Use arrow keys or / to search, space to start selection, enter to copy. To paste: Ctrl+b ]. Or just enable mouse mode: set -g mouse on in your config.

Nested tmux is awkward. If you SSH into a server that's already running tmux, and you start tmux again, the prefix key collides. Send the prefix to the inner session by pressing Ctrl+b twice.

The daemon runs as your user. If someone else logs in as you, they can tmux attach and watch your session. Not a problem for a Pi on your desk. Worth knowing on a shared box.

Can you do this on Windows?

Tmux itself is POSIX-only. It will not run on plain Windows.

But you have three good options:

1. WSL2. Windows Subsystem for Linux gives you a real Linux kernel. Install Ubuntu from the Microsoft Store, then sudo apt install tmux. Works exactly like on a real Linux box. This is what I'd recommend for local use.

2. SSH into a Linux box from Windows. PowerShell has had a built-in ssh client since Windows 10. Open PowerShell, ssh pi@raspberrypi.local, then run tmux on the Pi. The fact that your client is PowerShell is irrelevant — tmux runs on the Pi, not on your laptop.

3. PowerShell on the agent side? No. PowerShell as a shell works fine inside tmux on Linux (install pwsh, run it inside a tmux session). But if your agent is a Windows-native PowerShell script that needs Windows APIs, tmux can't help. Use Start-Job, Register-ScheduledTask, or run it as a Windows service instead. Or move the agent to WSL2 and use tmux there.

The short answer: if your agent runs on Linux (including a Pi or WSL2), tmux is the right tool. If it has to run on native Windows, use Windows' own background-job mechanisms.

A minimal config worth having

Drop this in ~/.tmux.conf:

# More scrollback
set -g history-limit 100000

# Mouse support (scroll, resize panes, click to select)
set -g mouse on

# Start window numbering at 1
set -g base-index 1

# Reload config with Ctrl+b r
bind r source-file ~/.tmux.conf \; display "Config reloaded"

Reload with tmux kill-server and start fresh, or Ctrl+b :source-file ~/.tmux.conf.

Alternatives worth knowing

screen — the original terminal multiplexer. Still works. Installed by default on more systems than tmux. Syntax is different but the idea is the same.

nohup and & — nohup ./agent & runs a command immune to SIGHUP and detaches it. Fine for fire-and-forget. Useless if you need to interact with the agent later.

systemd units — the right answer for anything that should survive reboots and restart on failure. Overkill for ad-hoc agent runs. Perfect for production.

zellij — modern tmux alternative. Nicer defaults, better discoverability. Worth a look if tmux's keybindings annoy you.

For an agent you babysit interactively but don't want tied to your laptop: tmux. For an agent that should run forever: systemd.

Final thought

Run the agent the normal way if that works for you. Terminal in VS Code, hit go, watch it work.

But if you've already got a Pi or a small server running — use it. It doesn't go to sleep. Your laptop does.

Run the agent on the thing that stays awake.

tmux new -s ai

And close the lid without guilt.