New Claude Code sessions lose all the context the old one had. How do teams persist it?

A new Claude Code session starts empty on purpose, so persisting context means deciding where each kind of context lives. Teams use three layers. Your own unfinished task comes back with claude --continue or claude --resume. Task state that someone else will pick up goes into files the repo carries: a spec, a handoff note and the project CLAUDE.md. The history behind the code, meaning the PRs, tickets and Slack threads that explain why things are the way they are, stays where it lives and gets queried over MCP. Session context is everything Claude learned during one conversation: the files it read, the dead ends it ruled out, and what you told it. What you don't move into a layer is mostly gone next time.

What Claude Code keeps on its own, and what it drops#

Anthropic's docs are direct about it: "Each Claude Code session begins with a fresh context window" (Claude Code memory docs). Two things load into every new session. CLAUDE.md files hold instructions you write, and the project file is "shared with your team through version control" (same page). Auto memory is the set of notes Claude writes for itself; the first 200 lines or 25KB of its index load at start. The same page says it "is machine-local" and its files "are not shared across machines or cloud environments" (memory docs). What Claude learned on your laptop does not reach your teammate, or your own cloud session.

The full conversation is saved too, also locally, under ~/.claude/projects/ with a default 30-day retention (Claude Code sessions docs). The problem is not unique to Claude. A February 2026 paper says coding assistants "lose coherence across sessions, forget project conventions, and repeat known mistakes" (arXiv 2602.20478).

Long sessions lose detail even before they end. When the window fills, Claude Code compacts the conversation into a summary. Project-root CLAUDE.md, auto memory and the plan written in plan mode are re-injected from disk (Claude Code context window docs). Everything else is summarized. Anthropic's overview of how Claude Code works warns that "detailed instructions from early in the conversation may be lost" and gives the fix: "Put persistent rules in CLAUDE.md rather than relying on conversation history."

Layer 1: resume your own session#

Resuming is the cheapest option for your own unfinished work. Anthropic's workflow guide says "Claude Code saves every conversation locally," and claude --continue "resumes the most recent session in the current directory" (Claude Code common workflows). For work that runs across days, name the session with /rename auth-refactor and come back with claude --resume auth-refactor.

A resumed session restores the messages and tool results, starting from the last summary if it was compacted. Two limits matter for teams. The transcript lives on the machine that wrote it, so a teammate cannot resume your session. And a week-old transcript full of failed attempts often does worse than a clean start. Anthropic recommends /clear between unrelated tasks, because a focused context gets better answers and costs less (Claude Code best practices).

Layer 2: write task state into files the repo carries#

Anything a second person or a second session needs should be a file. A handoff note is a short file, written by the agent before the session ends, that records what changed, what was ruled out and the next step. Anthropic's pattern is to have Claude write a SPEC.md, then "start a fresh session to build from it, so the build begins with a clean context and a written definition of done" (best practices, linked above). Three files cover most handoffs:

• The spec: what done looks like and what is out of scope.
• The handoff note: for example, "retries moved to the queue consumer, client-side retry reverted, next fix the flaky timeout test". Have Claude write it before you /clear, then commit it or paste it into the PR description.
• Project CLAUDE.md: only durable facts a new teammate would also need, such as build commands. Keep it under 200 lines, since longer files "reduce adherence" per the memory docs. The CLAUDE.md audit guide shows what to cut.

Other tools follow the same split. Cursor notes that "Large language models don't retain memory between completions," so its project rules "are version-controlled" (Cursor rules docs). GitHub's Copilot Memory keeps repository facts that "are shared with your collaborators." Copilot checks each fact against "the current branch to judge whether the information is still accurate," and facts expire after 90 days by default (GitHub Copilot Memory docs). Written context goes stale, so prune it like code. The arXiv paper above used the same approach at scale: 34 on-demand specification documents for a 108,000-line C# system.

Layer 3: keep the history queryable, not copied#

The hardest context to persist was never in a session: why the retry limit changed, which approach was rejected in review, who owns the billing service. It already lives in PRs, issues, design docs and Slack threads. Copying it into CLAUDE.md does not scale; the file bloats and goes stale. Memory tools that store per-developer notes help with recall but not with this, as why Claude Code forgets your codebase explains. The institutional memory post walks through how agents rebuild rejected work when this history is missing.

The durable fix is to let every session ask. Unblocked is a context engine that indexes code, PRs, issues, docs and Slack or Teams together. It returns one cited answer to Claude Code, Cursor and other MCP clients, filtered to what the asker is allowed to see. Its context_research tool runs "multi-source research across code, PRs, docs, issues, and messaging" and "returns a synthesized answer with citations" (Unblocked MCP docs). Because the answer is built from the source systems each time, a new session, a new teammate and a cloud agent all draw on the same history.

Which layer to use for what#

An agent that re-reads the codebase at the start of every task is a separate problem, covered in how to stop repeat discovery. The test for this one: open a new session on a teammate's laptop and ask it to continue your task. Whatever it gets wrong shows which layer is missing.