Multi-session workflows
Working with Claude on Projects
A single session with Claude can be productive. A well-managed project that spans dozens of sessions can be transformational — but only if each session starts from a shared foundation and ends cleanly. This chapter covers how sessions work, how context compaction affects long conversations, and the practical patterns for keeping a long-running project coherent over weeks and months.
The Lifecycle of a Session
The gap between sessions is a hard reset of the conversation. The only things that survive are what's written to files — memory, CLAUDE.md, and anything Claude generated on disk. Everything else is gone. Managing that transition is what multi-session workflow design is about.
Context Compaction — What Happens When a Session Gets Long
Within a single session, Claude's context window fills as the conversation grows. At approximately 80% capacity, Claude Code automatically compacts older portions of the conversation — replacing them with a summary — to free space for new turns. This happens in the background; you may see a note that compaction occurred.
The summary is accurate but lossy — it captures decisions and outcomes, not exact wording. What this means in practice:
- General decisions and outcomes survive well — "we chose PostgreSQL over MySQL" will be in the summary
- Exact code snippets from early in the session may be paraphrased — the logic is captured, not the literal text
- Nuanced constraints may soften — "never use nano, always vim" may become "prefers vim" after compaction
- Important specifics should go to memory files — if something needs to survive compaction precisely, write it down before the session gets long
Starting a Session Well
The first message of a new session sets the context. Claude has loaded your instructions and memory files, but has no knowledge of what happened last session. A good session opener orients Claude immediately:
- →State where you are. "We're on chapter 6 of the VPN course" or "Continuing the FastAPI meal planner — last session we finished the recipe schema." Claude uses this to load the right memory files and calibrate its responses.
- →State what's changed since last session. If you made decisions or did work outside of Claude between sessions, say so. Claude can't know what happened in the gap.
- →Name the first task. Don't make Claude guess. "Let's do vpn5 today" is faster than "what should we work on?"
- →Flag any context drift. If you want Claude to check its memory for something ("do you remember what subtopic_id we used for the VPN course?"), ask explicitly — Claude won't proactively surface memory it thinks you already know.
Ending a Session Well
The end of a session is the highest-risk moment for information loss. Before closing:
Save anything important that isn't already in files
If you made a decision mid-session ("we're going to use Redis for the session store") that isn't reflected anywhere on disk, ask Claude to save it: "Remember that we decided to use Redis for session storage — update the project memory file." If Claude generated code that exists only in the chat, confirm it's been written to disk.
Update status tracking
If you use a prompt map with a status table (✅/⬜), make sure it's been updated to reflect what was completed this session. This prevents confusion about where you are when you resume.
Note the logical next step
Ask Claude to write a one-line note to the project memory file: "Next session: vpn6 — OpenVPN clients." It takes five seconds and means the next session opener is obvious.
Handoff Patterns — Resuming After a Break
Forces Claude to read the course memory file and give you an accurate status. Use when you've been away and aren't sure what was completed.
When you know exactly where you are. The most efficient opener — no status check needed, gets straight to work.
Asks Claude to surface a specific fact from memory. More reliable than trying to remember it yourself — if it was saved, Claude has it.
Use when the project has evolved significantly since the last session and memory files may be slightly behind. The re-brief overrides stale memory for this session.
When you did work outside Claude between sessions. Brings memory up to date before the session begins rather than mid-session.
This project's shorthand for a three-section status report: completed courses, started but incomplete, proposed but not started. One word, full picture.
Keeping Long Projects Coherent
Projects that span weeks or months face specific challenges — memory files go stale, preferences evolve, earlier decisions get forgotten. A few maintenance habits prevent gradual drift:
Periodic memory consolidation
Run /consolidate-memory (or ask Claude to review and consolidate memory files) every few weeks on active projects. This merges duplicates, removes stale entries, updates facts that have changed, and sharpens one-line MEMORY.md hooks. A memory system that isn't maintained slowly degrades.
Spot-check before acting on memory
If Claude references a fact from memory that you'll act on — a file path, a config value, a decision — verify it against the current state before proceeding. Memory captures what was true when it was written. Things change.
Keep CLAUDE.md current
Review it when the project changes significantly. A CLAUDE.md that describes an old tech stack or references files that no longer exist actively misleads Claude. It's better to have a shorter, accurate CLAUDE.md than a comprehensive but stale one.
Don't let memory grow without pruning
MEMORY.md has a 200-line soft limit. A project that accumulates memory files without ever removing them will eventually have a bloated index where Claude can't reliably select the right files. Quality over quantity: ten focused memory files beat forty vague ones.
Common Multi-Session Problems
| Problem | What causes it | Fix |
|---|---|---|
| Claude seems to have forgotten a preference | The preference was stated in a session but never written to a memory file | Ask Claude to save it now; add to feedback memory. Then it persists. |
| Claude contradicts an earlier decision | The decision is in a memory file but the description isn't specific enough to load it | Update the MEMORY.md hook to be more specific; check the memory file still accurately reflects the decision |
| Progress tracking is wrong | The status table in the course memory file wasn't updated after a chapter was completed | Update the table now; add "update status table" to the automatic behaviours in CLAUDE.md |
| Claude references a file that doesn't exist | A memory file recorded a file path that has since moved or been renamed | Update or remove the stale reference; use /consolidate-memory to catch these systematically |
| Session starts slow — lots of clarifying questions | CLAUDE.md or memory files are too thin to establish context quickly | Invest in the CLAUDE.md project overview and tech stack sections; they load every session and eliminate the most common questions |