Your refactor agent was halfway through a migration. Tests were running on a cloud VM. Your local terminal disconnected, the browser refreshed, or your laptop slept. The process may still be alive, but the instructions, output, and decision trail are suddenly split across shells, machines, and whatever you can remember. Knowing how to recover AI sessions is less about reopening a chat and more about restoring the development state around it.
For AI-assisted coding, a session has several layers: the agent's conversation and working context, the terminal process it launched, the repository state it changed, and the machine where the work is happening. Recovery succeeds when you identify which layers survived and avoid making the situation worse with duplicate commands or premature cleanup.
Start by classifying what failed
Do not immediately restart the agent. First determine whether you lost the interface, the connection, the process, or the actual machine. Those are different failures with different recovery paths.
If the browser tab crashed but the agent runs in a persistent terminal or remote environment, the underlying process may still be working. If an SSH connection dropped, the remote process may have survived unless it was attached directly to that shell. If the laptop rebooted and the agent was running locally without a persistent session manager, the process is likely gone. A cloud VM restart is more serious, but repository changes and logs may still be recoverable.
The fastest first check is operational: inspect the machine, then inspect the process, then inspect the repository. Treat the chat history as useful evidence, not the only source of truth.
Check whether the process is still alive
Reconnect to the original machine and look for the agent process, its child processes, and any active test, build, or package-manager job. Inspect CPU and memory before assuming that apparent inactivity means failure. An agent can be waiting for a test suite, an API response, a compiler lock, or a prompt that is no longer visible in your client.
If you use persistent terminal sessions, reconnect to the existing session instead of starting a new one. Tools such as tmux, screen, systemd services, containers, and remote development environments can preserve work across a disconnect. The trade-off is that persistence keeps processes alive even when they are stuck, so recovery should include a quick health check rather than blind trust.
Read the last output carefully. Look for the command in progress, files touched, errors, and any question the agent asked. If it was waiting for approval, answer that request. If it was running a destructive command, stop and verify the repository state before allowing anything else to continue.
Recover the repository before you recover the conversation
Git gives you a more reliable recovery record than an agent transcript. Start with the working tree. Check modified, staged, untracked, and deleted files. Review the latest commits and inspect the diff rather than accepting every generated change because the task sounded familiar.
A useful recovery sequence is simple: identify the active branch, inspect the diff, run the narrowest relevant test, and read the failure before making more edits. If the agent committed changes, inspect the commit graph and the commit message. If it did not commit, the working tree is still your evidence.
Be especially careful with parallel agents. Two agents may have edited the same files, changed the same dependency, or reached conflicting conclusions from different test runs. Before restarting anything, establish ownership of the branch and decide whether the unfinished changes should be preserved, reverted, or moved to a separate worktree.
For risky work such as migrations, broad refactors, lockfile changes, or infrastructure edits, create a checkpoint commit once you understand the current state. A checkpoint is not an endorsement of the code. It is a recoverable marker that lets you compare the next agent run against a known point.
Reconstruct the task from durable artifacts
When the original AI conversation cannot be restored, rebuild the context from artifacts that outlive the session. Read the issue or ticket, the branch name, terminal history, recent commits, changed files, failing test output, and notes left in the repository. These are usually enough to write a much better resume prompt than, "Continue where you left off."
A strong resume prompt names the current branch, summarizes verified progress, lists files changed, includes the exact failure or remaining acceptance criteria, and states what the agent must not redo. For example: "On branch `billing-retry`, the retry policy is implemented in the worker and tests pass except for the integration test timeout. Inspect the current diff first. Do not rewrite the queue client or modify unrelated files. Diagnose the timeout and propose the smallest fix."
That prompt gives the new agent a bounded job. It also prevents a common recovery failure: an agent sees incomplete work, assumes it is wrong, and replaces it with a second implementation.
How to recover AI sessions across machines
Multi-machine work adds a second problem: you may not remember where the agent was actually running. A local terminal can control a remote VM, while Git changes appear in a shared repository and logs exist on a third system. Recovery needs a machine map, not just a list of open tabs.
Identify the host for each active task. Record the repository path, branch, terminal session, agent name, and whether the process is local or remote. Then check machine health: uptime, available disk, CPU load, memory pressure, and network status. Resource exhaustion can look like an agent failure when the real cause is an out-of-memory kill, a full disk, or a stalled build cache.
A visual workspace helps because the machine, terminal, repository activity, and agent context stay visible together. In 49Agents, persistent panes on one canvas can keep those relationships available after you return, rather than requiring you to reconstruct them from terminal titles and browser history. That matters most when several Claude sessions, repositories, and remote machines are moving at once.
Do not broadcast recovery commands until you know each terminal's state. A command that is safe for an idle shell may interrupt a running migration or test process elsewhere. Broadcasting is useful for benign checks, such as printing a status, checking the current branch, or collecting process information. It is not a substitute for situational awareness.
Decide whether to resume, restart, or replace the agent
Resuming is best when the original process is alive and its context remains available. You preserve momentum, tool state, and the chain of reasoning that led to the current edits. The downside is that a long-running agent may be operating on assumptions that are now outdated, especially if another developer changed the branch.
Restarting is best when the process died but the repository state is clear. Give a new session a concise handoff with validated facts. Keep the scope narrow and ask it to inspect before editing. This is often faster than trying to recreate every turn of a lost conversation.
Replacing the approach is best when the agent repeatedly loops, produces broad changes without validation, or cannot explain the current failure. Save the useful artifacts, discard the unreliable plan, and start with a smaller task boundary. A recovered session should reduce uncertainty, not preserve it for sentimental reasons.
Make the next recovery cheaper
The best session recovery system is built before a crash. Use branch names that describe active work. Keep terminals named by repository and task. Commit checkpoints before risky changes. Put long-running work in persistent sessions. Save agent handoffs in issue notes or a short `STATUS.md` when a task will span days or machines.
For each active agent, make four details visible: what it is doing, where it is running, what branch it owns, and what evidence will prove completion. That can be a test command, a deployment check, a benchmark, or a reviewable diff. If one of those details is missing, recovery becomes guesswork.
You do not need to preserve every token of every AI conversation. Preserve the operational context that lets a developer or a new agent make the next correct move. The next time a session disappears, pause before launching another one, inspect what survived, and hand off from evidence instead of memory.