plain-language glossary
what is session persistence?
Session persistence means you can come back to work without rebuilding everything by hand. That sentence hides several different guarantees. A detached live process, a saved workspace layout, an agent conversation restored after a restart, and a persistent cloud disk are different things. Know which one your tool actually provides.
four persistence cases
| case | what remains | what to expect |
|---|---|---|
| detach and reattach | client leaves; host keeps the server and processes alive | Herdr's strongest path; original processes keep running |
| app or server restart | saved session and worktree state returns; processes need recovery | layout returns; supported agents can resume native sessions |
| host sleep | nothing executes while the host sleeps; use qualified awake-host setup | processes pause until the host wakes |
| cloud volume stop/start | repos, worktrees, and config can persist on the volume | disk data returns; running processes don't |
Current details: Herdr session state and restore · Herdr persistence and remote access · Pane Remote Control docs · Pane Cloud Workspaces docs
detach is the easy case
Detach means the client stops displaying the session while the host keeps it alive. tmux, Zellij, and Herdr use this model. You can close a terminal or lose an SSH connection, then reattach while the original shell or agent is still running.
- → the host stays awake
- → the server stays running
- → the original process keeps its memory and state
- → reattach shows the live session
restart means recovery
When an app or session server restarts, the old process may be gone. A tool can still restore the saved workspace shape, working directory, focus, and recent screen. Some agents expose their own session IDs, so an integration can resume the conversation. A generic shell or unsupported process starts fresh.
- → layout restore isn't process restore
- → screen history isn't a live shell
- → native agent resume depends on the agent and integration
- → a crashed agent can still need a human or an orchestrator to continue it
sleep is a host power question
No session layer can make a sleeping computer run code. If you need unattended progress, keep the host awake with a qualified power setup or use an always-on machine. Pane documents idle-sleep and lid-closed setup separately. Its optional Pane Chat resilience can help resume a turn that died during a sleep or network error, but it's recovery, not dark-wake execution.
- → idle-sleep prevention is different from lid-closed setup
- → battery sleep can pause work
- → a crash or lost network can end an agent turn
- → recovery tooling can continue a task after the host returns
cloud storage isn't process immortality
A cloud workspace volume can keep repositories, worktrees, configuration, and history across a VM stop and start. That protects data. It doesn't keep a shell, test, or agent process alive while the VM is stopped. Start the machine, reconnect the client, and recover the session when needed.
- → volume persistence protects files
- → an always-on VM protects live execution
- → snapshots help before destructive changes
- → remote clients still depend on a reachable host
how to choose the guarantee you need
Use this quick check before you leave an agent running.
- For a short network drop, use a live server and reattach. Herdr, tmux, and Zellij are built around this path.
- For a laptop restart, check whether your tool restores layout, screen history, or the agent's native conversation.
- For overnight work, keep the host awake while plugged in or move the runtime to an always-on remote machine.
- For cloud stop/start, verify volume persistence and plan to restart processes after the VM returns.
- For a failed agent turn, inspect the last output and continue only after you know what the agent was waiting on.
primary references
keep reading
Last updated September 14, 2026