After the reboot: bringing a whole team of coding agents back, not one pane

What a reboot really kills

Start with what stays. The transcript of a Claude Code conversation is a file on disk: a JSONL file under ~/.claude/projects/, one per session, named after the session id. Codex keeps its sessions under ~/.codex/sessions/. A reboot does not touch those files. Time can: a dev.to write-up of 29 September 2026 mentions Claude Code’s 30-day cleanup of old transcripts.

What goes is the process. A write-up from Quil (14 June 2026) puts it plainly: the transcript survives on disk, but the session is “tied to the running claude process”. Stop the process and nothing reattaches to the file by itself.

tmux does not close the gap by itself. When tmux restarts (a reboot, a crash, tmux kill-server), tmux-resurrect and tmux-continuum bring back windows, panes and directories, as a February 2026 write-up on tmux-assistant-resurrect says, “But the AI sessions that were running inside them are gone.” Quil’s write-up says of the same plugins that you get back “the shape of the workspace, not the running work”. A Claude Code issue of 16 March 2026 put the same thing as a request: “there’s no way to restore Claude sessions after a system reboot or tmux kill-server”, because the session id could not be read from outside the process. It was closed as a duplicate, and the manual commands in the next section are the workaround.

It is not only reboots. In an open issue in the cmux tracker, dated 28 September 2026, the process the agents ran under got a SIGTERM and, in the reporter’s words, “every agent terminal drops to a bare shell at once”: 24 Claude sessions and 3 Codex sessions in one window. Recovering them “took an agent about 15 minutes of screen-scraping”: read each exit banner for the session id, check that no agent was still alive there, type a resume command back. That was a killed launcher, not a reboot, but the state you are left in is the state a reboot leaves.

The manual way, and a script

For one session the fix is one line. In the project folder, claude --continue reopens the most recent Claude Code session there, and codex resume --last does the same for Codex. Both, as the dev.to write-up says, pick the most recent session from the current directory. claude --resume and codex resume --all show a picker across projects.

For several, the same write-up lists your recent sessions with a small jq script. It reads the transcript folders of both tools and prints a cd … && claude --resume <id> line (or the codex resume <id> equivalent) for each of the ten most recent sessions, and you run the lines.

That is cheap, honest and enough for three sessions. The cost is in the tenth: minutes of your time, and the memory of which folder held which job. And note what the script cannot know. It lists conversations. It has no idea which of them was the lead, which was the reviewer, or what either was waiting for.

The tools that remember session ids

A group of small tools closes exactly that gap. They keep the session ids next to the panes and resume them for you. We read their own pages and issues; we have not run them, so what follows is what they say about themselves.

• tmux-assistant-resurrect. Its author’s write-up (16 February 2026) says it saves pane layouts, finds running assistants by inspecting processes, takes their session ids through native hooks or plugins, and on restore resumes each conversation: Claude Code, OpenCode and Codex. The same page is straight about maturity: built over a weekend, “limited real-world usage so far. Expect rough edges.”
• Quil, a terminal multiplexer. It registers a SessionStart hook for each Claude Code pane and records the current session id every time it changes; OpenCode sessions are tracked the same way. After a reboot it brings the panes back on the recorded ids.

These tools solve the session part well, and if you run a few agents in tmux, that may be all you need. Note what is in their scope, though: panes and conversations. A role, a line of reporting, a task in flight and the last messages are not things a terminal knows about. In the table, the last row is harnsy’s own claim and it is marked “partly” for panes for a reason: it opens the agents again in its own tmux, not in your old layout.

The part that is not a pane: the team

Ask yourself about your last restart. Did you remember who reported to whom, which task was in review, what the last messages were? We could not find people writing about this directly, so read this section as an observation from running agents in roles, not as a survey of complaints.

The closest neighbour is Claude Code’s own agent teams, and its documentation is candid. Under Limitations: “Agent teams are experimental”, and “No session resumption with in-process teammates: /resume and /rewind do not restore in-process teammates. After resuming a session, the lead may attempt to message teammates that no longer exist. If this happens, tell the lead to spawn new teammates.”

A public issue asked for the same thing at the level of state. Its reporter (12 March 2026) says the team and task folders under ~/.claude/ were emptied at the next session start, and asked that a team created in one session be resumable in a later one. It was closed as “not planned”. We read the issue, not the reasons, and a feature marked experimental changes; take it as a dated report.

That is a different design from ours (teammates inside one session, not separate terminals), so it says little about harnsy. It does show where the gap sits. After a restart three things have to be back, and a resumed conversation is only the first:

• The sessions: each agent back on the conversation it was in.
• The relationships: which role each agent holds and who reports to whom.
• The work: the tasks in flight and the record of what was said.

How harnsy keeps the team

In harnsy a role is a stable post and an agent sits in it. The seat remembers the session it holds and every session it has had: a Claude Code session id, an OpenCode ses_… id or a Codex thread id, with the directory and the launch settings. A role with no live holder shows as offline.

Roles, seats, tasks and the message log live in harnsy’s own database, not in a terminal. They are simply there after the machine comes back, as long as harnsy’s node is running again; we have not verified that it starts by itself at boot.

Restore is a button on the Teams tab, per team: “reopen disconnected”. It shows only while a role is offline. It resumes the seat’s current session in the seat’s own directory with the harness’s own resume: claude --name <ref> --resume <id> for Claude Code, codex resume <id> for Codex, and the recorded session for OpenCode. The same is available from the command line, harnsy debug team restore, and for an agent as the MCP tool harnsy_restore. It is not a recent addition. It never opens a session twice: a role that is already running is skipped, and so is a role nobody holds.

Look at the two cards: the session ids are the same. The point is not that agents start again. It is that they start on the conversations they were in, in the roles they held, with the task board and the message log where they were. What you do next is what you do after any interruption: look at what was in flight.

You can see the restore for yourself: install harnsy, open a team, stop its agents on a quiet afternoon, and use “reopen disconnected”.

The limits, in one place

First, what is still there after a reboot and what is not:

And the limits that are not on that list:

• We have no recorded test after a real reboot. This is the design, not a measurement of a power cut.
• A message to a local agent that is down fails at once and is recorded as failed. harnsy does not resend it. For task executors, the lead gets an “undelivered” notice.
• It works with tmux 3.1 or newer on Linux and macOS, where harnsy starts its own tmux server. Windows support arrived in harnsy 0.8.0 and is still being verified.
• It walks the roles that have an agent seated on them, in Claude Code, Codex and OpenCode: a Claude Code or Codex agent you started by hand and seated on a role is restored too. OpenCode is limited to agents harnsy started. A seat without a recorded session id cannot be restored.
• We have not tested what restore does when the transcript is gone, for example after a cleanup.
• It never opens a session twice, with one blind spot: an idle Codex terminal that has shown nothing for over 30 seconds can look absent and be opened again.
• The number of agents that run at once is capped by the edition. A team that does not fit is refused whole rather than brought back in part. We give no figure for how many restore at once, because we have not measured it.
• If a resumed Claude Code agent registers under another name, its role stays offline until the agent is seated on it again.
• Do not release an agent that merely went offline: release drops the session id that restore needs.

A checklist for any setup

None of this needs harnsy. If you run more than a couple of agents, these hold with any tool:

• Name every session, so that a list of ids means something.
• Keep the transcripts. If you rely on them, find out how long your tool keeps them, and raise it.
• Write a handover note before a planned stop, as you would before a holiday. Roles, not personas shows what goes in one.
• Keep the list of roles and tasks outside the terminals: a file or a board, not the conversation.
• Have one command that lists what should be running, so you can compare it with what is.
• Test the restore before you need it: stop everything on a quiet afternoon and see what comes back.

Sources

• cmux, “Recover every agent session that dropped at once”, 28 September 2026: github.com.
• Claude Code, agent teams, Limitations: code.claude.com.
• Claude Code issue on agent teams state, 12 March 2026: github.com.
• Claude Code issue on session ids and terminal restore, 16 March 2026: github.com.
• “How to pick up Claude Code and Codex sessions after a restart”, dev.to, 29 September 2026: dev.to.
• “Never Lose an AI Coding Session Again”, 16 February 2026: timvw.be.
• “Resume Claude Code Sessions After a Reboot, Automatically”, Quil, 14 June 2026: quil.cc.