Your agent needs a working session — here's the tmux pattern that prevents vanishing work

Your coding agent is brilliant for 30 minutes, then it forgets everything. You ask it to run tests, it can't find the files it just created. You ask it to check the server status, it has no idea what's running. Every conversation starts from scratch.

The problem isn't memory — it's that your agent has no persistent workspace. It's like hiring a developer who gets a completely clean desk every time they sit down.

Here's the fix: give your agent a tmux session that survives conversations.

A working session is a persistent environment where your agent can leave files, run long processes, and pick up where it left off. Think of it as your agent's desk that doesn't get cleared every night.

Most people try to solve this with better memory systems or longer context windows. That's backwards. Your agent doesn't need to remember what it did — it needs to see what it left behind.

The tmux workspace pattern

Start every agent conversation by attaching to a named tmux session:

tmux new-session -d -s agent-workspace 2>/dev/null || tmux attach-session -t agent-workspace

Now your agent has a persistent shell that survives disconnections, conversation resets, and even system reboots (if you configure tmux to persist).

But here's the key: structure the workspace with windows for different concerns:

# Window 0: Main development
tmux new-window -t agent-workspace:0 -n "main"

# Window 1: Tests and builds  
tmux new-window -t agent-workspace:1 -n "tests"

# Window 2: Servers and monitoring
tmux new-window -t agent-workspace:2 -n "servers"

# Window 3: Scratch work
tmux new-window -t agent-workspace:3 -n "scratch"

Your agent can now switch between contexts without losing state. Working on a feature? Window 0. Need to run tests? Window 1. Check if the development server is still running? Window 2.

The workspace initialization script

Don't make your agent set this up every time. Create a workspace bootstrap script:

#!/bin/bash
# ~/.local/bin/agent-workspace

SESSION="agent-workspace"

# Create or attach to session
tmux new-session -d -s $SESSION 2>/dev/null || {
  echo "Attaching to existing workspace..."
  tmux attach-session -t $SESSION
  exit 0
}

# Set up windows
tmux rename-window -t $SESSION:0 "main"
tmux send-keys -t $SESSION:0 "cd ~/projects && clear" Enter

tmux new-window -t $SESSION:1 -n "tests"
tmux send-keys -t $SESSION:1 "cd ~/projects && clear" Enter

tmux new-window -t $SESSION:2 -n "servers"
tmux send-keys -t $SESSION:2 "cd ~/projects && clear" Enter

tmux new-window -t $SESSION:3 -n "scratch"
tmux send-keys -t $SESSION:3 "cd /tmp && clear" Enter

# Start in main window
tmux select-window -t $SESSION:0
tmux attach-session -t $SESSION

Now your agent just runs agent-workspace and gets a fully configured development environment.

The session status check

Train your agent to check session status before starting work:

# Check what's running across all windows
tmux list-windows -t agent-workspace -F "#{window_index}: #{window_name} - #{pane_current_command}"

# Check specific window content
tmux capture-pane -t agent-workspace:2 -p | tail -10

Your agent can see what processes are running, what the last output was, and where it left off. No more "I don't have access to that" when it literally just created the file in window 1.

The persistence layer

Add tmux-resurrect to make sessions survive reboots:

# In ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'
set -g @resurrect-capture-pane-contents 'on'

Now your agent's workspace survives everything. It can pick up a debugging session from yesterday, check on a server it started last week, or resume a test run that was interrupted.

Warning: Don't let your agent create nested tmux sessions. Always check if you're already in tmux with echo $TMUX before creating new sessions.

This changes everything. Your agent stops being a stateless chatbot and becomes a persistent development partner. It remembers not through conversation history, but through the actual state of its working environment.

The best part? This pattern works for any kind of agent work — not just coding. Research sessions, data analysis, content creation — anything that benefits from persistent state and long-running processes.