AI Session Handoffs

Claude Code uses a finite context window. Its official documentation, checked 17 July 2026, says older tool output can be cleared and conversation history summarized as that window fills; detailed instructions from earlier turns may be lost even when key requests and snippets are preserved. The same docs say each new session starts with a fresh context window. This is Claude-Code-specific behavior, not evidence that every tool loses the same fields in the same way.

The convenient framing is “lost productivity”. The more consequential one is missing or stale verification state. A receiving session may not know what was checked, deferred, assumed, or superseded. That creates a review risk - the same boundary that motivates the spec-vs-implementation check, stretched across time. The June 2026 preprint on delegation contracts frames records of “what was asked, allowed, returned, and evidenced” as inputs to reviewability. It does not test this handoff format or establish continuity, reproducibility, recovery, or defect outcomes.

1. Keep stable truths in the instruction file. Architecture, conventions, constraints - official Claude Code documentation says project-root CLAUDE.md is loaded into fresh sessions and re-injected after compaction. It is context, not enforced configuration. Rules only; no work state.
2. Write the handoff before the session ends. Claimed state, decisions with reasons, evidence and limits, assumptions, open risks or conflicts, operator-owned decisions, and the next step - concise enough to review.
3. Store it in the repository. A handoff.md next to the code (or per work stream) can be versioned and diffed. Access, path discovery, and retention remain separate configuration concerns.
4. Start the next session from it. First instruction: read the handoff, then compare its revision, claims, and evidence with the current repository and run state.
5. Close the loop.Items in “open” remain listed until a named operator resolves, accepts, or escalates them. The file alone cannot enforce that process.

STATE      rate-limit header work · 2 of 3 tasks done
           [done] Retry-After on 429 · [done] unit tests
           [in progress] CDN passthrough check

DECISIONS  header value = window rest, NOT fixed 60s
           (matches RFC 6585 guidance; discussed with mk)

VERIFIED   criteria 1,2,4 PASS (see soll-ist-check.md)
OPEN       criterion 3: header visible behind CDN - needs
           staging access · DO NOT assume it works

NEXT       run staging check, then close criterion 3
           and update the evidence report

• Transcript dumping. A handoff is a state snapshot, not a chat log. An oversized dump can hide the decisions and risks the receiver needs to review.
• Letting the model write it unreviewed. The session summarizing itself inherits its own blind spots - fine as a draft, but the human confirms what is actually open versus done.
• Bloating the instruction file. Work state pasted into CLAUDE.md can become stale context that a future session treats as current. Keep volatile state separate.
• Handoff without verification status. “Where I stopped” without “what is unverified” hands over the work but not the risk - the next session needs both.
• Stale, partial, or conflicting state. Timestamp the snapshot, name its source revision, and surface conflicts. The repository, current run, and fresh checks outrank a handoff that no longer agrees with them.
• Treating transfer as approval. Evidence and open risks can move between sessions; human acceptance, release, and escalation decisions do not happen merely because the file was read.

Reality Graph can assemble a handoff from declared task state, boundaries, verification results, and open points in the structured task and its evidence report. Open points that outlive one session can also be carried as a ticket the next run starts from, so a single file is not the only place the work survives. Those records can be stored in your environment and reviewed as part of the verification loop. They remain claims and evidence with timestamps and limits; they do not guarantee continuity, completeness, recovery, correct interpretation, or operator approval.