How to Keep Claude Code Context Between Sessions

Claude Code can carry context across sessions, but no single feature does every part of the job.

Use claude --continue when you want to reopen the most recent conversation. Use claude --resume when you want to choose an earlier session. Put stable project instructions in CLAUDE.md. Let auto memory retain useful patterns Claude discovers. Write a structured handoff when you need to start a fresh session without losing the immediate state of the work.

That setup works well for many projects.

The harder problem appears later: your project now spans dozens or hundreds of sessions, decisions have changed, rejected approaches keep returning, and several true-at-the-time statements disagree. At that point, you do not only need more memory. You need a maintained answer to a different question:

What is currently true about this project?

This guide explains the native options first, gives you a practical setup you can use today, and shows where each method starts to break.

The five ways to carry Claude Code context

There are five useful layers, and they solve five different problems.

Method	Best for	What it does not solve
Resume a session	Continuing the same line of work	Unifying decisions across many independent sessions
CLAUDE.md	Stable instructions and conventions	Automatically updating project state when decisions change
Auto memory	Reusable learnings and patterns	Establishing which remembered claim currently governs
Structured handoff	Starting a fresh session with the latest working context	Maintaining a complete, reconciled history over months
Maintained project state	Current decisions, rejected paths, evidence and open questions	Replacing the native tools that already work well for instructions and short-term continuity

The mistake is not choosing the “wrong” one. It is expecting one layer to do all five jobs.

1. Resume the same Claude Code session

When the work is still one coherent conversation, resuming is the simplest and strongest option.

Claude Code saves sessions locally. You can continue the most recent session with:

claude --continue

Or choose a previous session with:

claude --resume

The shorter forms are:

claude -c
claude -r "<session-name-or-id>"

Inside Claude Code, /resume opens the session picker. Naming important sessions with /rename makes them easier to find later.

Resuming is stronger than starting a new session with a summary because it reopens the existing conversation under the same session ID. The prior discussion, tool calls and checkpoints remain part of that conversation.

Anthropic’s documentation is careful about the distinction: a new session begins with a fresh context window, while a resumed session continues an existing conversation. See the official guides to how Claude Code works and Claude Code best practices.

Where resuming starts to break

A project is rarely one conversation forever.

You may split work across branches, open parallel sessions, abandon one approach, return to another, or start fresh because the current context has become crowded. Resuming preserves one thread. It does not reconcile the project-level conclusions scattered across every thread.

After enough time, “Which session should I resume?” becomes the wrong question. The information you need may be distributed across ten of them.

2. Put stable instructions in CLAUDE.md

A CLAUDE.md file is the right place for information Claude should apply in every session:

• the commands used to build and test the project;
• coding conventions;
• important directory boundaries;
• architectural constraints that are genuinely stable;
• instructions about how work should be verified;
• rules that should remain visible after compaction.

Claude Code loads CLAUDE.md as persistent context. You can place files at different scopes, and use .claude/rules/ for more targeted instructions. Anthropic’s current memory documentation describes CLAUDE.md as the user-written layer for instructions and rules.

A useful CLAUDE.md might include:

# Project

A local-first TypeScript application.

# Commands

- Install: npm ci
- Test: npm test
- Build: npm run build

# Durable rules

- Preserve backward compatibility in the public API.
- Never modify generated files by hand.
- Run the focused test before the full suite.
- Do not commit secrets, local paths or customer data.

This is exactly the kind of information that belongs there.

Instructions are not the same as project state

The trouble begins when changing decisions are stored beside stable rules.

Suppose CLAUDE.md says:

Split each new module into its own service.

Two months later, after measuring the operational cost, you decide:

Use a monolith-first approach and extract only proven hotspots.

The later decision may be correct and binding, but it happened in a session or meeting. Unless someone edits CLAUDE.md, the next session still receives the old instruction.

The file did not fail to load. It faithfully loaded a statement that used to be true.

That is why CLAUDE.md becomes a maintenance job on a long-running project. The more project state you put into it, the more often it must be reconciled against decisions made elsewhere.

Use CLAUDE.md for durable instructions. Be cautious about turning it into the sole database of everything the project currently believes.

3. Use auto memory for reusable learnings

Claude Code also has auto memory. It can save notes such as build commands, debugging discoveries, code patterns, architecture observations and preferences that may be useful in future sessions.

Auto memory is different from CLAUDE.md:

• you write CLAUDE.md;
• Claude writes auto memory;
• both are loaded as context in future sessions;
• neither should be treated as mechanically enforced configuration.

This is useful when Claude discovers, for example:

• a test fails unless a local service is started first;
• a package has an unusual import convention;
• a particular mock is the reliable way to reproduce a bug;
• you prefer a certain verification workflow.

You can inspect and control auto memory with /memory. Anthropic documents its current storage and behavior in How Claude remembers your project.

Recall does not establish authority

Auto memory reduces repetition. That does not automatically make every memory the project’s current approved position.

A system can remember:

• “We planned to use event-driven synchronization.”
• “The prototype now uses scheduled synchronization.”
• “Revisit events after the load test.”

All three may be accurate records of things that happened. The project still needs to know:

• Which approach is in force?
• Was the old one rejected, deferred or merely not selected?
• What evidence caused the change?
• Who approved it?
• Is the question now open again?

This is the difference between AI memory and a maintained project state. Memory helps surface what was said. A maintained state determines what currently governs, while preserving the history underneath it.

4. Write a structured handoff before starting fresh

Sometimes a fresh session is the right move. The current context is crowded, the task is changing, or you want a clean thread for implementation after a long investigation.

A good handoff is much better than “continue where we left off.”

Use a fixed structure:

# Current objective

What we are trying to finish now.

# Current state

What is already implemented or established.

# Decisions in force

- Decision
- Why it governs
- Evidence or file references

# Rejected or deferred paths

- Path
- Why it was rejected or deferred
- What would justify reopening it

# Open questions

- Question
- What is known
- What remains unresolved

# Verification completed

- Tests run
- Results
- Known limitations

# Next action

The smallest correct next step.

The sections matter more than the prose.

A weak handoff says what happened. A strong handoff separates the conclusion from the history: current decisions, rejected paths, unresolved questions, proof and next action.

Keep the handoff current, not cumulative

Do not append every handoff forever and ask the next session to read all of them. That recreates the original problem in Markdown.

Keep one current handoff for the active workstream. Archive previous handoffs for traceability, but make it explicit which file is current.

For a project that is still manageable by hand, a simple structure can work:

CLAUDE.md
docs/
  project-state.md
  decisions.md
  open-questions.md
  handoffs/
    current.md
    archive/

A useful division of responsibility is:

• CLAUDE.md: stable instructions;
• project-state.md: concise current state;
• decisions.md: decisions in force, with rationale;
• open-questions.md: unresolved issues;
• handoffs/current.md: the immediate continuation point.

This is not magic. Someone still has to keep these files true. But it makes the maintenance job explicit instead of hiding it inside one growing context file.

5. Maintain project state when the work outgrows handoffs

The manual setup stops scaling when the project changes faster than you can maintain its context files.

Typical signs include:

• the project spans months and many independent sessions;
• you repeatedly correct Claude about a decision already made;
• old architectural or product choices reappear as new proposals;
• two context files disagree and nobody knows which is current;
• a summary carries the latest choice but loses what it replaced;
• a decision matters, but its evidence and rationale are buried;
• parallel sessions produce conclusions that need reconciliation;
• the cost of acting on an obsolete assumption is now meaningful.

At this point, the problem is not missing storage. The transcripts, files and commits usually still exist. The problem is that the project’s current truth has fragmented across them.

Search can find an old decision. It cannot tell you by itself whether that decision still holds. A summary can describe the sequence. It may flatten a reversal into one smooth paragraph. A memory layer can retrieve both the old and new statement. It does not necessarily decide which one is authoritative.

A maintained project state should preserve a smaller, stricter set of things:

• decisions currently in force;
• the evidence and rationale beneath them;
• what each decision superseded;
• paths deliberately rejected, and why;
• questions still open;
• conflicts that require a human decision;
• revisions approved by a person.

That is the missing layer between a project’s raw history and the next action taken by a human or AI agent.

It is also why long-running AI projects lose their own history even when nothing was deleted, and why rejected paths are so expensive to forget.

A practical setup to use today

You do not need a new product to improve continuity this afternoon.

Start with this:

For one task across multiple sittings

Resume the same named session.

claude --resume

For stable behavior across every session

Keep a concise CLAUDE.md focused on commands, constraints and conventions.

For discoveries Claude should reuse

Review auto memory with /memory. Correct or remove notes that should not carry forward.

Before opening a fresh session

Write a structured current handoff with decisions, rejected paths, open questions, verification and the next action.

Once a week on a serious project

Reconcile the handoff and decision files against what actually changed. Explicitly mark old conclusions as superseded instead of silently deleting them.

Before Claude acts on a high-impact assumption

Ask for the source:

What is the current decision, what did it replace, and where was it approved?

If the answer is reconstructed from several plausible fragments, treat it as a proposal for review — not as established project state.

Does Claude Code remember previous sessions?

Claude Code provides several forms of continuity, but the answer depends on what you mean by “remember.”

It can reopen saved conversations with --continue or --resume. It loads user-written instructions from CLAUDE.md. Auto memory carries selected learnings across sessions. Your files, git history and local session transcripts also remain available.

A completely new session, however, begins with a fresh context window. It does not automatically contain the full conversation history of every previous session. Native continuity mechanisms selectively bring forward different kinds of information.

Is CLAUDE.md persistent between sessions?

Yes. Claude Code loads applicable CLAUDE.md files as persistent context in future sessions.

The important limitation is operational, not technical: the file stays persistent even when a decision inside it has become obsolete. Persistence tells you the text will return. It does not guarantee that someone kept the text current.

What is the difference between CLAUDE.md and auto memory?

CLAUDE.md contains instructions and context you deliberately write. Auto memory contains learnings Claude chooses to save while working.

Use CLAUDE.md when you want explicit control over stable rules. Use auto memory for reusable discoveries and preferences. Review both. Neither one, on its own, is a complete governance system for changing project decisions.

Should I use one long Claude Code session?

Use one session while the work is coherent and the context remains useful. Resume it when continuing the same workstream.

Start a new session when you need isolation, a different task, or a cleaner context. Before doing so, create a structured handoff. Long sessions are not inherently better; continuity is only valuable when the carried context is still relevant and correct.

When do I need more than memory and handoffs?

You need a stronger system when maintaining the context has become a project of its own — especially when decisions change across sessions, contradictions matter, rejected paths keep returning, or a wrong assumption can waste meaningful time or money.

The goal is no longer to remember everything. It is to preserve one human-approved current state while keeping the evidence and revision history behind it.

Bring one real project to the Founding Beta

Propperly’s Project Continuity Founding Beta is being prepared for Claude Code power users running long-lived work and tired of maintaining project context by hand.

The intended workflow is local-first: use explicitly selected project folders and Claude Code sessions, reconstruct decisions and open questions, require human review before the maintained state changes, and expose the approved state back to Claude Code through MCP.

It is a small guided beta, not a generally available product.