Feature Request: Session Handoff / Continuity Support

That's a pretty clean implementation, but this domain is quite active right now. I've worked out a similar solution. So has the next person who might comment here, and thousands and thousands of others. There are numerous YouTube videos on the topic, papers, conversations about it at the local bar.

So this surfaces the question: what makes your solution better than mine, better than the guy sitting next to me on the bus, better than what Anthropic employees scaffold out on occasion?

It's definitely something that should be a native feature in Claude Code, but I wonder if it isn't because there are so many ways to tackle this - and many would rather take a day to establish their own framework for cross-session continuity, than adopt an opinionated external framework.

https://ampcode.com/news/handoff

Thanks for the update, @towry. Awesome feature.

Strong support for this. Session handoff is table stakes for any serious development workflow.

Real scenario:

Day 1: Start complex refactoring task, build up context about codebase architecture, decisions made, approach chosen.

Day 2: Session is gone. Re-explain everything. Lose the nuance of why certain decisions were made.

Day 3: Same thing. Eventually give up on complex multi-day tasks in Claude Code.

What's needed:

1. Explicit session save - /save-session my-refactoring-project
2. Session resume - claude --resume my-refactoring-project
3. Session export - Portable format for backup/sharing
4. Auto-checkpoint - Periodic saves during long sessions

Integration with claude.ai:

Ideally, saved sessions could be accessible from claude.ai too. One context, multiple interfaces.

The ask:

Either implement session continuity, or permit users to build their own continuity tools by allowing programmatic access to our own sessions. We're paying $200/mo - we should be able to preserve our own work.

Using amp at work, I can confirm that handoff is incredibly useful. That said, it might be hard to implement this well. Everything depends on the quality of the prompt that it generates for its future self.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I wonder what is meant by "occurring" in this context, but the feature request remains. It is certainly worthy of a non-automated response.

Here I am in Feb 2026, figuring this out organically and building it now, only to come across this.

Can we have the standard now? I'm probably sticking with my own solution but it's kind sad to see this hasn't been solved to a general state yet.

Built an open-source CLI that solves this: npx handoff-md , analyzes your repo and generates a HANDOFF.md for any AI model. github.com/guvencem/handoff-md

Built an open-source CLI that solves this: npx handoff-md , analyzes your repo and generates a HANDOFF.md for any AI model. github.com/guvencem/handoff-md

I haven't tested, but reviewed the repo. I'm a big fan of lean and mean, no-BS resources. This looks to be one of them. Thanks for the share, and it's likely yet another good reference, if handoff-md isn't used directly. I had something quite similar ~1 year ago, when working with the "cutting edge" AI friends of the time, when contexts were much smaller and things in general weren't as wild as they are now... I never took the time to share it with anyone, because I figured "_there's no way 57,002 others aren't already doing this, including the proud parents of these totally-not-sentient AI_"... wish I'd slapped a repo up to spark a fire around the concept!

Keep up the good work, and thanks again for sharing.

Maybe it didn't exist when this issue was filed, but I am confused now this isn't met with --continue or --resume already, all sessions are already persisted and resumable. There is also /export for a markdown-formatted copy of a session.

I _would_ like a first class way to move a session to a different machine though, e.g. from a CI system to local. I can hack something together by moving the session dir with JSONL but seems fragile.

Working Implementation: Plan-Aware Session Handoff via Slash Commands + Hooks

We've been running into this exact problem daily — especially when using Superpowers for plan-driven development. The workflow breaks at the plan→execution boundary: you spend significant context building a plan, then either (a) clear context and lose the reasoning, or (b) keep context and run out of room executing.

What we built (working today)

Two slash commands that bridge the gap using existing Claude Code infrastructure:

/create_handoff — Run before ending a session or when context is high. It:

1. Locates the active plan file (Superpowers docs/superpowers/plans/*.md or native .claude/plans/)
2. Captures git state (branch, last commit, uncommitted changes, test status)
3. Records key decisions and gotchas that aren't in the code
4. Writes specific "what to do next" steps with file paths
5. Saves to thoughts/shared/handoffs/{session}/handoff-{date}.md

/resume_plan — Run at the start of a new session. It:

1. Finds the most recent handoff + plan file
2. Compares current git state with what the handoff expects
3. Reports discrepancies
4. Offers to continue via subagent-driven or inline execution

How it connects to existing hooks

We have a Stop hook (auto-handoff-stop.py) that blocks at 70% context usage and tells you to run /create_handoff. A SessionStart hook (session-start-continuity.sh) auto-loads the handoff in the next session. A PreCompact hook saves continuity state before compaction.

Why this matters more than just "write a markdown file"

The key insight is that the handoff must be plan-aware. A generic summary loses the structure. The handoff needs to know which tasks from the plan are done, which remain, and what the next concrete step is — not just "continue the refactor."

What we'd love natively

The three primitives already exist: plan files on disk, background Agent tool, TaskOutput monitoring. Wiring them together at ExitPlanMode (as proposed in #30510/#30438) would eliminate the manual /create_handoff step entirely. Even a simpler /compact option (instead of full context clear) at plan exit would help enormously — per #38244.

Happy to share the full command implementations if useful.

— Boris @ 199 Biotechnologies

I feel like many devs have built a similar system within their own workflow. I'm using a session memory schema with a heartbeat.md/Claude.md set-up and automatic updates of those files on a rolling basis.

My own mantra is - Each dev cycle creates the tools to repeat itself. Everything built is a single use case containing a general application seed crystal. Memory is the Upgrade. The more Persistence we can automate the better.

Posting for anyone searching for the cross-machine, same-CLI flavor of this:

@neoacar/claude-handoff — an open-source CLI that packages a Claude Code session (main transcript + subagent transcripts + memory/ + metadata) into .claude-shared/ in the repo, rewrites absolute paths to portable placeholders, redacts secrets, and reconstructs the bundle on the receiver's machine so claude --resume lists it with the original title and full history intact.

How it differs from what's already in this thread:

• --resume + /export (@stbenjam): both exist and are great — but --resume only finds sessions in the local ~/.claude/projects/, and /export produces a markdown copy for humans, not a resume-able transcript. This tool makes the actual session JSONL travel between machines.
• handoff-md (@guvencem): generates an AI-agnostic markdown summary. Different goal — great for prompting a fresh session. This one preserves the real transcript so you don't lose fidelity on resume.
• Amp's handoff (@towry): Sourcegraph product, not applicable to Claude Code specifically.

Works today for single-machine → another-machine handoff through a git repo. Install: npm install -g @neoacar/claude-handoff. Feedback welcome.

This is extremely well thought out, and the fact that you've already built and validated the manual version (next-session.md + archive) proves the need is real.

Having implemented essentially this same pattern (but as an MCP memory server rather than file-based), a few observations:

What works better than handoff files: Structured, queryable memory that any session can read/write at any time — not just at session boundaries. The handoff-at-exit pattern has a failure mode: if the session crashes or the user just closes the terminal, the handoff never gets written. And it requires the next session to start from the handoff, rather than any session being able to query "what's the current state of X?"

I built Recall for this — open-source MCP memory server (MIT licensed) that provides persistent, queryable memory across sessions:

• remember — store a fact, decision, or task state at any time during a session (not just at exit)
• recall — search for relevant memories from any session. "What were we working on?" returns the answer.
• Multi-agent coordination — claim/release/handoff primitives let agents formally transfer context to each other
• No crash-loss risk — facts are written to disk immediately, not buffered until session end
• Works with any MCP client — Claude Code, VS Code Copilot, Cursor, Warp, etc.

Your "multi-step workflow" example would look like:

Session 1: remember("API schema: designed, 12 endpoints, OpenAPI spec at /docs/api.yaml")
Session 2: recall("API schema") → gets the state, implements endpoints
           remember("API: 12/12 endpoints implemented, tests at /tests/api/")
Session 3: recall("API status") → deploys to staging

Each remember is immediate — no session-end hook needed. Any session can query at any time.

uvx ai-recallworks to try it. GitHub: https://github.com/RecallWorks/Recall

Hit the same multi-day-context-loss problem and built a workaround: https://github.com/yacb2/claude-session-handoff. It closes the current claude and opens a fresh one with a handoff prompt seeded as additionalContext via the SessionStart hook, plus a systemMessage banner so the user can see they're in a handoff session. Trigger via a handoff: prefix (zero tokens, UserPromptSubmit hook), a /handoff slash command, or a natural-language skill. Doesn't auto-archive — that still needs the official SessionEnd prompt hook you propose.

Adding my vote here. Even with claude agents you basically run into this problem. Need an official handoff or way to spawn another agent. Main goal is to avoid context bloat, among other things of course.

The shift from handoff files to persistent queryable memory (@stevepaltridge) is the right direction. Writing context at session boundaries is fragile — crashes lose everything, and you can only query at start/end, not mid-session.
I've been building Context Cloud along similar lines — an MCP server where any session can read/write structured knowledge at any time, no hooks or session boundaries needed. A few things that came out of the build process that might be useful to this thread:
Typed knowledge matters. Raw text memory gets noisy fast. Context Cloud chunks everything into types — decision, finding, convention, state, question, reference — so when a session recalls context, it can differentiate "this is a decision we made and why" from "this is where things currently stand." Helps a lot with the stale-context problem several people mentioned.
Cross-tool is the unlock most people don't expect to need. Works across Claude (web/desktop/Code), Cursor, Codex, Windsurf. You commit a decision from Claude Code, recall it from Cursor tomorrow. Turns out most teams use more than one AI tool.
Team memory is the layer nobody here has built yet. Shared workspaces with roles, email invites, attribution on every chunk. Your teammate commits context from their session, your session recalls it. This is where individual continuity becomes team continuity — the handoff isn't a file, it's a shared knowledge layer that's always current.
Eval results: 99.4% accuracy on our test suite, 94/100 on a 20-session stress test with evolved facts and adversarial phrasing. Detail capture at 95.7–97.1%.
Free to try: contextcloud.pro | npm: @contextcloud/mcp-client | GitHub

Adding a note from the persistence/durability angle that hasn't been covered yet in this thread.

The "stateless session" framing in the original report is exactly right, but the thing that makes it a production problem rather than just an inconvenience is the interaction with compaction. When a session auto-compacts, the handoff file or continuation prompt you prepared for the next session is now decoupled from the session that produced it — and if the user resumes without realizing compaction happened, they're starting from partial state without knowing it.

We hit this building a multi-project GTM polling runner where each cycle dispatches 2–3 Claude Code agents in sequence. The pattern that works without native support:

1. Each agent writes a structured completion record to a shared state file before exiting (completed_at, outcome, key context for successor)
2. The external scheduler (not Claude) reads the record and injects it as the opening context for the next session
3. The session's only job is to do its work and write the record — continuity is the coordinator's responsibility, not the model's

This is basically the "context injection at session start" pattern @stevepaltridge described, operationalized at the scheduler layer rather than the hook layer. It's more robust than file-based handoffs alone because the scheduler can verify the record was written before spawning the next session.

The native feature that would eliminate the external plumbing entirely: a first-class SessionEnd hook that persists a structured summary, keyed by project + workflow ID, and a matching --resume-workflow <id> flag that injects it at session start. That's the minimal surface needed to make multi-day orchestration not require an external process babysitting it.

(Disclosure: I build Claudiverse — an agent orchestration tool built on top of Claude Code. The pattern above is what we do today. The feature request in this issue would make the native experience match what you'd expect from a production-grade tool.)

Strongly support this. One behavioral nuance from heavy real-world use worth folding in:

Beyond save-on-end / load-on-start, the high-value habit is read-before-acting + flag-divergence: before interpreting ANY new instruction or data mid-session, the agent re-reads the relevant handoff/log and checks the request against the recorded plan — and explicitly flags mismatches instead of advising from a blank slate.

In one long multi-topic session this caught the agent's own premature conclusions four separate times — each time the logs corrected it before I had to. So the handoff isn't just for session boundaries; consulted continuously, it becomes the source of truth that stops the agent re-deciding things already settled. Worth making "consult the handoff before acting" part of the default, not just "write it at the end."

I'm building a Claude/Codex session sharing platform, currently only supporting public sessions. Have a look here: https://joe-store-frontend.onrender.com

https://github.com/TomSOhm/claude-session-port , here's the cross-machine flavor, close to what @stbenjam proposed: moving a session machine-to-machine (CI→local).
It packages one session's real JSONL (so claude --resume actually resumes it, full history intact) into a single .tar.gz. No cloud, no git remote, no account; you pick the transport. Path/home remap handles cross-OS.

Credit where due: @NeoAcar's claude-handoff (above) does the same core thing, and goes further with default secret redaction and batch export, so it's worth a look. However, mine is a standalone tarball needing no repo, installs as a Claude Code plugin with slash-command, includes a helper that resolves each /resume picker row to its UUID by file size.

Tested on Windows so far; actively looking for macOS/Linux and cross OS export/import testers to confirm a moved session resumes. Not a substitute for a native feature, just a stopgap that works today.