Recover an AI coding session from the work that survived.
A practical guide to rebuilding AI coding context from disk truth instead of trusting a bloated transcript or hoping the old model can summarize itself.
Try the free recovery path first.
- Check the tool's session history. Many coding tools retain local conversations or offer a continue or resume action. In Claude Code,
claude --continueresumes the most recent conversation andclaude --resumelets you select one. Use the equivalent history feature in your tool if it exists. - Inspect the working tree. Run
git status --short,git diff --stat, andgit diff. Check untracked files separately. Do not assume every changed file belongs to the interrupted task. - Locate durable notes. Look for a project README, task file, issue, recent commit message, or handoff note. Treat each as context to verify, not as proof that the work is done.
- Run the smallest relevant check. A failing test, typecheck, or build gives the next session a concrete starting point. Record the command and its actual result.
- Write a short handoff. Capture the goal, files changed, decisions, failed approaches worth avoiding, remaining uncertainty, and one next action. Start a fresh session only after this note is grounded in the current files.
If the provider is temporarily unavailable or a usage limit was reached, waiting and resuming the same session may be enough. Do not move tools merely because a chat paused. If the history cannot be recovered or the session's assumptions are stale, the repository becomes the primary source of evidence.
What AI coding session recovery means.
When a coding agent gets too long, stale, rate-limited, deleted, or untrusted, the old transcript stops being a safe source of truth. It contains useful decisions, but also abandoned branches, failed attempts, and assumptions that may no longer match the code.
For a closer look at why the diff cannot carry the whole task, see a breakdown of what survives and what is lost when a coding session dies, including the distinction between disk state, model context, and unwritten intent.
Recovery means rebuilding the working state so a fresh AI session can continue the task without the human manually reconstructing everything from memory.
Different failures need different responses.
Dead session.
The old chat cannot continue because usage is exhausted, access is blocked, or the provider is unavailable.
Stale session.
The chat still exists, but it is carrying old attempts, wrong assumptions, and too much noise.
Deleted session.
The chat history is gone or not trustworthy, but the repo still has changed files and git state.
Tool switch.
You started in Claude, Cursor, Codex, Gemini, or another tool and now need the next AI to pick up cleanly.
What a recovery packet should include.
Why chat summaries are not enough.
A summary depends on the old AI still being alive and honest about its own state. It may also keep too much of the wrong material: obsolete reasoning, abandoned branches, or vague claims about files it never checked.
A transcript can be valuable for decisions and negative knowledge, but it should not overrule the current files, command output, or test results. Label remembered intent as intent and observed state as evidence. If a previous attempt failed, include the failure and why it failed so the next agent does not repeat it.
These concerns also came up in informal research notes from conversations with 50+ developers about session loss. Those observations are useful context, not a controlled study or a substitute for checking your own working tree.
Make a handoff file without buying anything.
Create a short local note outside generated files. The note should be small enough that a new session can read it before touching the code. Include only information that changes the next decision. A useful example is:
Goal: finish the interrupted refactor of the upload flow.
Current state: src/upload.ts and tests/upload.test.ts changed; no commit yet.
Verified: typecheck passed; upload test failed on the empty-file case.
Rejected: retrying the old parser did not handle empty files.
Constraint: preserve the public API and existing user changes.
Next: inspect the failing assertion, fix one branch, rerun that test.
Compare the note with git diff before you hand it to another agent. Include relevant untracked files, but keep secrets, private logs, credentials, and customer data out of the packet. If the repository is not under Git, use the editor's file history and the filesystem to identify changes, then state that your evidence is weaker.
The next agent should begin by reading the note and checking the files, not by immediately implementing from the note alone. Ask it to identify contradictions, distinguish verified facts from guesses, and propose one small next step. This avoids turning a plausible handoff into a second source of stale assumptions.
When a tool-specific resume is better.
If the original session is intact, its built-in resume command preserves more conversational context than a manually reconstructed packet. Use it when the task is still small and the conversation remains reliable. If the session is bloated, a compact or clear command may be available, but review any resulting summary against the working tree. A compacted chat is not a test run.
Claude Code can auto-compact when its context fills, and you can use /compact deliberately. Context compaction may keep a live session going, but its summary still needs checking against the current files and test results.
Claude Code also stores local session transcripts under ~/.claude/projects/*.jsonl. Those files can help locate an earlier conversation, but their presence does not prove the repository still matches what the conversation described.
For Claude Code specifically, see the session recovery guide for --continue, --resume, and local history. If the issue is context saturation rather than a lost session, use the context-limit guide for /context, /compact, and /clear. Other coding tools expose different history controls; check their current documentation before relying on a remembered command.
How ShardStitch does it.
If manual handoffs become repetitive, ShardStitch can help assemble a continuation packet from local project state, Git changes, recovery notes, and other surviving evidence. It formats the result for supported AI handoff targets. Review any generated packet before sharing it, especially across tools with different data-handling boundaries. It cannot recreate thoughts or unsaved work that never reached disk.
Related guides.
FAQ.
Is this different from /compact?
Yes. /compact is useful when the old session is alive and you want to stay in the same tool. Recovery is for when the session is too stale, blocked, untrusted, or moving tools.
Does ShardStitch need the old AI session alive?
No. It can rebuild a continuation packet from local disk state, project files, git diff, notes, and memory.
What should be left out?
Drop raw transcript history, abandoned branches, and reasoning that did not change a decision. Keep constraints, decisions, failed attempts that matter, and the next action.