Where did I leave that? Managing AI agent sessions across machines

Running a coding agent has been getting easier for a while now. The hard part has quietly moved somewhere
else.

It's not the model. It's not the tooling. It's that you can't find the work you did yesterday.

See if any of this is you

• You have ten terminal windows open. Seven of them are called codex.
• You remember a session that had the tests almost passing. You don't remember which machine it was on.
• You closed your laptop, SSH dropped twice, and when you came back you weren't sure what you'd approved.
• One session has been running for two hours, and to see the step you actually care about you have to scroll back through three hundred tool messages.

None of these are about how smart the model is. They're about how your work is organized.

This is now an entire product category

Here's a funny way to see the problem clearly: there's a whole class of tools whose only job is answering
"where are my sessions?"

• cmux (198 points on HN) — a terminal with vertical tabs and notifications, because you have too many sessions.
• Agent-of-empires (118 points) — literally a session manager. Its own README states the problem better than I can: > "Each agent runs in its own tmux session, so your agents keep running when you close the TUI, > disconnect SSH, or your terminal crashes. Reopen aoe and everything is where you left it."
• Rudel (144) does session analytics. claude-replay (105) replays sessions like a video player. Ctx (72) adds a /resume that works across Claude Code and Codex. Skillsync (YC W26, 68) makes sessions portable between agents. Pizza Bot (61) gives agents an inbox.

Even the vendors agree that many sessions at once is normal. Anthropic ships docs titled
Orchestrate teams of Claude Code sessions (396 points on HN)
and Message your other Claude Code sessions
(173 points).

And their blog nails what bad session hygiene actually costs:

"In one session, Claude reads the test and the file it covers, makes the edit, and is done in a handful of
turns. In another, it greps around the repo first, reads a dozen files on its way to the same two, and
every one of those turns also drags along everything else that's been read into the conversation since
this morning."

Same fix. Very different bill.

All of those tools hit the same ceiling

Almost every one of them is single-machine and single-agent.

The moment your sessions live on several machines — one at home, one at work, one on a customer's box, one in
the cloud — the session manager can't see them, the replay tool can't replay them, and /resume can't find
them. Your session management silently drops to zero exactly when you need it most.

TaskHandoff organizes sessions around an idea called Story

TaskHandoff is an open-source (Apache-2.0) control plane. The unit it organizes work around is a
Story, and the documentation defines it in one line:

Story — Organize documents, sessions, preset actions, and automation by goal.

The key word is goal, not time. If your goal is "finish the payments refactor," that's one Story holding
the relevant documents, several sessions, the preset actions you keep reusing, and the automation around it —
instead of four terminals you have to remember.

Then there are three things sessions themselves do about the pain above.

1. The session list marks unread sessions.

"Session lists mark unread AI sessions so you can quickly find work that needs attention.
Switch sessions from the instance sidebar, AI board, or Story."

Three places to switch sessions, and anything you haven't looked at is flagged. That answers "what did I miss."

2. Compact mode shows you one turn at a time. This is the part I haven't seen anywhere else:

"TaskHandoff's default and distinctive session experience. It focuses on one selected task turn and
keeps only the prompt, AI response, live tool activity, approvals, queue, and sub-agent state needed for the
current decision. This greatly reduces interference from long histories and repetitive process messages."

A two-hour session stops burying today's decision under hundreds of process messages.

And importantly, it doesn't achieve that by throwing data away:

"Compact mode does not summarize away or delete server-side session data. The complete history remains
available in Conversation mode."

3. Conversation mode is there when you need to dig.

"Use it to reconstruct a task, find an earlier prompt or result, audit approvals and retries, or
understand context across multiple turns."

And one line in the docs is the whole answer to "across machines":

"During a reconnect, TaskHandoff reloads the authoritative session snapshot.
A temporary Reconnecting state does not imply that the background task stopped."

Switch devices, lose the connection, come back — you get the authoritative snapshot, not a partial cache, and
"reconnecting" doesn't mean your background work died.

One more thing worth stealing: Story decisions. When a session produces something that needs a human
call, it doesn't get buried in chat — it becomes a pending item in the approvals queue. "Something is waiting
on you."

Quick start

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

• Repo: https://github.com/edgestorage/task-handoff
• Docs: https://docs.thandoff.com/en/sessions/

The line worth ending on

The last line of TaskHandoff's own "recommended practice" section is:

"Save important results in project files or Story documents, not only chat history."

Chat history disappears. Goals don't.

Honest caveats

Story isn't magic that tidies your sessions for you. It gives you structure — grouping by goal, unread
markers, a pending-decisions queue — and whether you use that structure is still down to your own habits.

If you only have one project on one machine, most of this won't matter to you yet. It's built for people
whose sessions have already started to sprawl.

TaskHandoff is also still Beta — the README says plainly that breaking changes may land between releases.

---