blog

~ ❯ cat blog/close-the-window.md

Close the window. Keep the agents.

· opcodezero

An agent in the middle of a twenty-minute refactor is a bad thing to lose to a stray ⌘Q. In most setups the agent lives in your terminal window: close the window, lose the process, and with it whatever the agent was halfway through. So you learn not to close windows, and your terminal becomes something you’re careful with instead of something you use.

wrkstrms moves the agents out of the window.

A server holds the panes

The first time you run ws, it starts a server in the background and attaches your terminal to it. The server is the same ws binary, running in its own session so a hangup from your terminal doesn’t reach it. It owns every pane and every program in them, and it draws the screen. Your terminal runs a thin client that sends keys and mouse events and shows what the server draws.

your terminals

Ghosttyattached
another terminal, laterws attach

the ws server (keeps running)

  • claude · opus
  • codex · gpt-5
  • nvim
  • pnpm dev :5173
state-default.dbsaved every few seconds, for restore after a crash or reboot
Your terminal is only a window onto the server. Close it and the panes keep running; attach again from any terminal.

This is how tmux works, for the same reason: with the interface in the server, any terminal can attach, with nothing to install.

Detach, attach

⌃␣ d detaches. So does closing the terminal window or tab. Either way only the client exits; the server and everything in it keep running, including an agent in the middle of a turn. Run ws again, from that terminal or any other, and you get the same screen back, exactly as you left it.

One terminal is attached at a time. Attach from a second one and it takes over; the first is told why.

What you come back to: everything still where it was, and the top bar saying what happened while you were gone.

That changes how a day feels. Close the terminal with three agents working, go do something else, open a new window, run ws, and the top bar tells you who finished and who is waiting.

After a crash, or a reboot

A server that keeps running is only half of it. Machines restart.

While it runs, the server saves the session every few seconds: every workspace and tab, each tab’s layout, each pane’s command, directory and label, and each agent’s kind, model, session id and last status. A clean quit clears the saved session. If the server stops any other way (a crash, a reboot, the power going out), the next ws offers to bring it back:

ws: the last session was saved: 2 workspaces, 5 tabs, 9 panes (3 agents).
Restore it? [Y/n]

Say yes and the layout comes back, every pane in the directory it was in. Agents resume their conversations: Claude Code with claude --resume and its session, Codex with codex resume, with the flags they were started with. Neovim reopens on its socket, dev servers restart their commands, and shells come back fresh.

Scrollback isn’t saved; agents keep their own transcripts, and resuming brings the conversation back.

More than one

ws -L <name> runs a separate server with its own panes, socket and saved session, the way tmux -L does: one for work and one for an experiment, say. wrkstrms’ own development runs its test builds on a server named dev, so they never touch the real one.

The short version

  • Your agents live in the server, not the window.
  • ⌃␣ d or closing the terminal detaches; ws attaches again from anywhere.
  • A crash or reboot costs you a Y at the next ws.

The Sessions guide covers all of it: attaching, restarting after an upgrade, named servers, and what exactly is saved.