Keep Claude Code Running After SSH Disconnects (tmux Guide)
Claude Code exits when you close your terminal because it receives SIGHUP. tmux is the fix — here's how to set it up, detach, and reconnect, with screen and nohup as alternatives.
Claude Code, OpenAI Codex CLI, and xAI Grok Build all die when your SSH connection drops — not because of a bug in any of these tools, but because of how Linux and macOS handle terminal processes. All three agents run as TUI (terminal user interface) processes that receive SIGHUP (hangup signal) when the controlling terminal closes. When the signal arrives, the process terminates immediately, taking your in-flight work with it. The fix is a terminal multiplexer like tmux, which decouples the agent process from your terminal session — or better, an always-on cloud VM where the problem cannot occur in the first place.
TL;DR: Run your agent inside a tmux session. When SSH drops, the agent keeps running. Reconnect with tmux attach. If you want to go further, move the agent to an always-on cloud VM (like a Daytona workspace) and the SSH disconnect problem disappears entirely — there is no laptop to sleep and no lid to close.
Why Claude Code, Codex, and Grok Build All Die on SSH Disconnect
When you SSH into a server and start a terminal agent, the SSH daemon creates a pseudo-terminal (PTY) and launches your shell as a child process. Your agent — whether Claude Code, Codex CLI, or Grok Build — is a child of that shell. When the SSH connection drops, the kernel sends SIGHUP to the controlling process group. Every process in that group, including your agent, receives the signal and terminates by default.
This is the same root cause for all three tools:
- Claude Code — terminal-bound TUI, receives SIGHUP, exits immediately
- OpenAI Codex CLI — same architecture, same behavior; GitHub issue #23132 tracks native detach support, open as of May 2026
- xAI Grok Build — launched May 14, 2026; same terminal-bound TUI, same SIGHUP behavior
With Anthropic doubling Claude Code rate limits in May 2026 (enabling sessions exceeding 45 minutes at P99.9), a lost session now represents substantially more wasted API spend than it did before. The stakes are real.
"Sessions die the moment you disconnect, losing all your Claude Code context. Standard SSH clients are terrible for AI CLI tools like Claude Code and Codex." — Reddit r/ClaudeCode
The Four-Layer Reliability Stack
Different failure modes need different fixes. Here is the stack ordered by what each layer protects against:
| Layer | Protects against | Tool |
|---|---|---|
| Sleep prevention | macOS lid close on local machine | caffeinate, pmset |
| Session persistence | SSH disconnect, terminal close | tmux, screen |
| Process recovery | Crashes, unexpected exits | PM2, systemd |
| Always-on infrastructure | Machine sleep, shutdown | Cloud VM (Daytona, Hetzner) |
Most guides stop at Layer 2. This guide covers all four — and explains why the order matters.
Layer 1: How Do You Prevent Your Mac from Sleeping During an Agent Run?
If you are running an agent on your local Mac and connecting to it remotely, macOS will sleep the machine and kill everything inside tmux when the lid closes. Prevent this first.
# macOS: prevent sleep for 8 hours
caffeinate -t 28800
# Or use the Grass CLI which handles this automatically:
grass start --caffeinate
For persistent settings across reboots:
# Disable display sleep and system sleep (macOS)
sudo pmset -a displaysleep 0 sleep 0
Windows users: PowerToys' Awake module or powercfg /change standby-timeout-ac 0 accomplish the same.
Sleep prevention only matters if you are running agents on a laptop. If you are on a cloud VM, skip this layer — the machine never sleeps.
Layer 2: How Do You Set Up tmux for Claude Code, Codex, and Grok Build?
tmux (terminal multiplexer) creates a persistent server process that owns your terminal sessions independently of any SSH connection. When your SSH connection drops, the tmux server keeps running. When you reconnect, you reattach to the exact session you left — agent still running, output preserved.
Install tmux
# Ubuntu/Debian
sudo apt install tmux
# macOS
brew install tmux
# Fedora/RHEL
sudo dnf install tmux
Claude Code: tmux Setup
# Start a named tmux session
tmux new-session -s claude-myproject
# Inside the session, start Claude Code
cd ~/projects/myproject
claude
# Detach (agent keeps running in the background)
# Press: Ctrl+B, then D
# Reconnect from any terminal on the same machine
tmux attach -t claude-myproject
For parallel Claude Code sessions across multiple repos:
tmux new-session -s claude-frontend
tmux new-session -s claude-api
tmux new-session -s claude-infra
List all active sessions: tmux ls
Session recovery flags exist but are last resorts, not prevention. claude --continue resumes the last session's transcript; claude --resume opens an interactive picker. Neither restores in-flight tool state — they only reload conversation history from the .jsonl file on disk.
Codex CLI: tmux Setup
Codex CLI has no native detach command as of May 2026. The tmux setup is identical to Claude Code:
tmux new-session -s codex-myproject
cd ~/projects/myproject
codex
# Detach: Ctrl+B, D
# Reattach: tmux attach -t codex-myproject
When you reattach to a Codex session, you are reconnecting to the live terminal process. The agent state is intact — no resume command needed because the session never actually dropped.
Grok Build: tmux Setup
Grok Build uses the same terminal process model. On a headless VPS, use the XAI_API_KEY environment variable for authentication instead of browser-based login:
export XAI_API_KEY=your-key-here
tmux new-session -s grok-myproject
cd ~/projects/myproject
grok build
# Detach: Ctrl+B, D
# Reattach: tmux attach -t grok-myproject
If the agent process does exit and you need to resume from Grok's session store:
grok --session latest # resume most recent session
grok -s <session-id> # resume specific session by ID
Grok Build's Plan Mode is worth enabling for long-running VPS tasks — it forces a plan review before execution, reducing the risk of losing unreviewed work on disconnect:
grok build --plan
What Does tmux NOT Solve?
This distinction trips up most developers setting up persistent agent workflows.
tmux is a process wrapper — it can only keep sessions alive as long as the machine running it stays on. Run tmux on your MacBook, close the lid, and macOS suspends the tmux server along with every session inside it. If your laptop battery dies overnight, the agent is gone.
tmux solves: terminal close, SSH disconnect, accidental window close, network drop mid-session.
tmux does NOT solve: laptop sleep, lid close, machine shutdown, power outage, or wanting to check in from a different device while your laptop is somewhere else.
"The key insight most guides miss: tmux is just a process wrapper. It can only keep a session alive as long as the machine running it stays on. Run tmux on a remote server, and that machine never sleeps. Run tmux on your MacBook, and closing the lid kills tmux along with everything inside it."
The correct fix for overnight or multi-day agent runs is tmux on a machine that never sleeps.
Layer 3: How Do You Eliminate the SSH Disconnect Problem Entirely?
Moving your agent to an always-on cloud VM does not just fix SSH disconnects — it eliminates the failure mode entirely. The machine never sleeps, never loses battery, and never has a lid to close. AI coding agents call remote APIs (Anthropic, OpenAI, xAI), so no GPU is needed — a modest CPU VM is sufficient.
Option A: Daytona Workspace (Zero-Setup)
Daytona is a developer workspace platform built specifically for always-on agent environments. Workspaces spin up in seconds with a reproducible dev environment.
# Install the Daytona CLI
brew install daytonaio/tap/daytona
# Authenticate
daytona login
# Create a workspace for your project
daytona create --repo https://github.com/your/repo
# SSH into it
daytona ssh my-workspace
# Inside the workspace, run your agent in tmux
tmux new-session -s claude
claude
# or: codex
# or: grok build
The Daytona workspace keeps running after you disconnect. Your agent inside tmux stays alive. Reconnect from any network or device:
daytona ssh my-workspace
tmux attach -t claude
The full setup walkthrough is at How to Set Up Claude Code on Daytona.
Option B: Bare VPS (Full Control)
A Hetzner CX22 runs approximately $7/month and is more than sufficient for terminal coding agents. After provisioning any Linux VPS:
# Install tmux and your agents
sudo apt update && sudo apt install -y tmux
npm install -g @anthropic-ai/claude-code # Claude Code
npm install -g @openai/codex # Codex CLI
# Grok Build: follow xAI install instructions
# Set your API keys
export ANTHROPIC_API_KEY=your-key
export OPENAI_API_KEY=your-key
export XAI_API_KEY=your-key
# Start working
tmux new-session -s agents
For API key security on a VPS, see How to Store Your API Key Securely When Running Coding Agents on a VPS.
Add Mosh for Reliable Mobile SSH Access
Mosh (mobile shell) is a UDP-based SSH replacement that survives network switches and phone sleep. Standard SSH drops on cellular handoffs and WiFi changes; Mosh reconnects automatically. Pair it with tmux on your cloud VM:
# Install mosh on the server
sudo apt install mosh
# Connect via mosh instead of SSH
mosh user@your-vps
# Reattach to your agent session
tmux attach -t claude-myproject
"Pair tmux + mosh and your phone just stays connected through all the network jank." — Reddit r/BlackboxAI_
Layer 4: Process Recovery With PM2 or systemd
tmux handles disconnects. PM2 or systemd handle crashes — they restart the agent process automatically if it exits unexpectedly.
# Install PM2
npm install -g pm2
# Run Claude Code as a managed process
pm2 start claude --name claude-myproject -- --dangerously-skip-permissions
# Persist restart policy across server reboots
pm2 save
pm2 startup
For systemd, create a unit file at /etc/systemd/system/claude-agent.service and enable it with systemctl enable --now claude-agent.
One caveat: agents that need interactive permission prompts forwarded will stall silently when running fully headless under PM2 or systemd. Address this with a permission forwarding layer before going fully autonomous.
Why nohup Breaks Interactive Agents
Several guides recommend nohup for keeping terminal processes alive. For AI coding agents, nohup is the wrong tool. It detaches stdin — the agent can no longer receive interactive input, including permission prompts. It also redirects stdout to nohup.out, which breaks TUI rendering. The agent stalls waiting for input it can never receive.
For Claude Code, Codex CLI, and Grok Build — all of which use interactive terminal interfaces — use tmux or screen, not nohup.
Using Grass to Monitor Agent Sessions From Your Phone
Once you have agents running on a cloud VM inside tmux, the remaining friction is visibility: checking in from your phone means opening SSH, reattaching to tmux, and reading raw terminal output. Grass is a machine built for AI coding agents that provides a purpose-built mobile interface — removing that friction entirely.
Install the Grass CLI on your cloud VM:
npm install -g @grass-ai/ide
# Start the Grass server inside a tmux session on the cloud VM
grass start --network tailscale
Scan the QR code with the Grass mobile app. From your phone, you can monitor agent output in real time, review diffs, and approve or deny permission requests from a native modal — no terminal required. The agent sessions running inside tmux keep working independently of whether the Grass app is open. When you reconnect, the live stream resumes from where you left off.
This is the combination that eliminates both failure modes at once: tmux on an always-on cloud VM keeps agents alive, and Grass gives you a mobile-native window into every running session from anywhere. One surface. Every agent. Always on.
Frequently Asked Questions
How do I keep Claude Code running after I close my terminal?
Run tmux new-session -s claude before starting Claude Code. Inside the tmux session, start claude. When you close your terminal or SSH disconnects, the tmux server keeps Claude Code running. Reconnect with tmux attach -t claude. If you need the session to survive your machine sleeping or restarting, run tmux on an always-on cloud VM instead of your laptop.
How do I prevent Claude Code from stopping when I disconnect from SSH?
Run Claude Code inside a tmux session on the remote server. SSH in, run tmux new-session -s claude, start Claude Code inside it, then detach with Ctrl+B followed by D. If SSH drops — intentionally or due to a network failure — Claude Code keeps running inside tmux. Reconnect with ssh user@server then tmux attach -t claude.
Does Codex CLI stop when SSH disconnects?
Yes. Codex CLI is a terminal-bound process that receives SIGHUP when SSH disconnects — identical behavior to Claude Code. The fix is the same: run Codex inside a tmux session. GitHub issue #23132 tracks a native detach feature for Codex, but it had not shipped as of May 2026.
Does Grok Build stop when SSH disconnects?
Yes. Grok Build, launched May 14, 2026, runs as a terminal TUI with the same SIGHUP behavior as Claude Code and Codex. Run it inside tmux on a remote server. For headless VPS authentication, use the XAI_API_KEY environment variable. Resume sessions with grok --session latest if the process exits.
How do I run Claude Code persistently without babysitting it?
The two-part setup: (1) run Claude Code inside a named tmux session on an always-on cloud VM or VPS, and (2) use a mobile client like Grass to check in without SSH. The agent keeps running when you are away from your desk, your laptop is closed, and you are not actively monitoring. You can reconnect from any device at any time.
What is the best setup for running an AI coding agent overnight?
Run the agent inside tmux on an always-on cloud VM — a Daytona workspace or a Hetzner CX22 VPS (approximately $7/month, no GPU needed). The machine never sleeps, so tmux sessions survive indefinitely. Add Mosh for reliable SSH access through cellular and WiFi switches. For permission-heavy agents, add a permission forwarding layer so approval prompts reach your phone instead of blocking the agent.
Can I use tmux on my laptop to prevent Claude Code from dying when I close the lid?
No — this is the most common misconception. tmux cannot survive laptop sleep or lid close. When you close your MacBook lid, macOS sleeps the machine and the tmux server is suspended along with everything inside it. tmux only solves SSH disconnects and terminal closes. To survive lid close, you need tmux running on an always-on cloud VM, not on your laptop.
How do I run Claude Code on a cloud VM?
Provision a cloud VM (Daytona, Hetzner, DigitalOcean, or any Linux VPS), SSH in, install tmux and the Claude Code CLI (npm install -g @anthropic-ai/claude-code), set your ANTHROPIC_API_KEY, and start Claude Code inside a tmux session. For a complete Daytona walkthrough, see How to Set Up Claude Code on Daytona.
Next Steps
The fastest path from zero to a persistent agent setup:
- 5 minutes: Install tmux on your current server and wrap your agent — Claude Code, Codex, or Grok Build — in a named tmux session.
- 30 minutes: Provision a Daytona workspace or a $7/month Hetzner VPS, move your agent there, and configure tmux. The machine never sleeps.
- Optional: Install Grass (
npm install -g @grass-ai/ide) on the VM and monitor every session from your phone without SSH.
"I've been running Claude Code locally for months. It works, but my laptop fan sounds like a jet engine, my battery drains in two hours, and if I close the lid mid-session — gone. Last week I moved my entire dev environment to a cloud VM." — DEV Community (Timothy Olaleke)
The difference between tmux on a laptop and tmux on a cloud VM is the difference between "survives SSH disconnect" and "survives everything." Agents on an always-on machine with mobile access through Grass are no longer tethered to your desk — you dispatch them from wherever you are, and they keep working whether or not your laptop is open.
Published by Grass — a machine built for AI coding agents. Claude Code, Codex, Open Code, and every agent you run, on an always-on cloud VM accessible from your laptop, your phone, or an automation.