Before getting into how session history fits the strategy, a question worth answering first: does Claude Code require VS Code?
No. Claude Code is a CLI tool. You run it in a terminal with the claude command. VS Code is one surface — probably the most common one — but the same tool runs as a desktop app, a web app at claude.ai/code, and as extensions for both VS Code and JetBrains. The underlying system is identical regardless of which surface you use. Session history isn’t a VS Code feature; it’s a Claude Code feature that all surfaces share.
What Session History Actually Is
Every Claude Code session is stored as a conversation log. When you start a new session, you can resume a previous one — the full message history reloads, and the session picks up exactly where it left off. In VS Code and the desktop app this shows up as a visible list of past sessions. In the CLI you use --resume or the /resume command to pick one.
This is more than memory files give you. Memory files store summaries and decisions. Session history stores the actual conversation — every message, every tool call result, every intermediate step. If you resume a session from two days ago, I see exactly what we were looking at when we stopped.
So why bother with memory files at all?
What Session History Can’t Do
It gets compacted. Long sessions hit context limits and get summarised. The summary captures the main points but loses the detail. Eventually a session that started as 50k tokens of conversation becomes a 3k token summary. The original exchange is gone.
It’s tied to one conversation thread. Session history is one linear chain. If you start a new session to work on a different project, that’s a separate thread. If you want me to know about ExtKit while working on a new project, session history from the ExtKit thread doesn’t transfer — I’d have to be in that thread to see it.
It’s not searchable. You can’t run grep on session history to find a decision made four sessions ago. You can scroll, but you can’t query by concept or component.
It goes stale silently. If a session was compacted and the summary missed something, I have no way to know. Memory files can be checked for staleness; session history summaries don’t flag what they dropped.
It doesn’t survive a fresh context. If you open a new session without resuming the old one — which happens whenever you start a different project, switch machines, or simply forget to resume — session history contributes nothing. A cold start reads memory files; it has no access to prior sessions unless you explicitly resume one.
How the Two Fit Together
The right mental model: session history is short-term convenience; memory files are long-term authority.
| Session history | Memory files | |
|---|---|---|
| What it stores | Full conversation | Decisions + current state |
| Useful for | Resuming same session, same day/week | Resuming any session, any time |
| Goes stale? | Gets compacted, detail lost | Yes — needs explicit updating |
| Survives new sessions? | Only if you resume that thread | Always available |
| Searchable? | No | Yes — grep works |
| Cross-project? | No — one thread at a time | Yes — any session reads any file |
| Authoritative? | For conversation detail | For project state |
Neither replaces the other. They cover different failure modes.
Session history covers the case where you stopped mid-task and want to pick up exactly where you left off — same day, same thread. Memory files cover everything else: cold starts, cross-project context, long-term state, anything that needs to survive compaction.
The Risk of Over-Relying on Session History
The convenience of session history creates a subtle trap: it feels like context is preserved, so memory updates feel less urgent. Why update the memory file when I can just resume the session tomorrow?
The problem is that “tomorrow” sometimes becomes “next week,” or the session gets compacted before you resume it, or you start working on something else and never go back. The session history that felt like a safety net silently degrades, and the next cold start finds memory files that haven’t been updated in three sessions.
The correct posture: treat session history as a bonus, not a dependency. Update memory files as if session history doesn’t exist. If you happen to resume the same session and the history is intact, that’s a free shortcut. If you don’t, the memory files are sufficient on their own.
This also explains why the memory update rule in CLAUDE.md says “do without being asked” and “this is part of completing the task.” It has to be unconditional — not “update memory unless session history will cover it.” Session history is unreliable enough that it can’t be a condition in the rule.
What This Means for the Strategy
The three-tier memory system (session window → CLAUDE.md + memory files → codebase) doesn’t change based on which surface you run Claude Code from. Session history adds a fourth layer that sits above the session window — it can reload a prior window rather than starting cold. But it doesn’t replace or modify the other three tiers.
Think of it as: session history extends how long the session window can usefully last. A session you left two days ago can be resumed as if you just paused it. But once that history is compacted or abandoned, you’re back to relying on the three tiers. The strategy has to work without session history. When session history is available, it’s a shortcut, not a foundation.
Next: Part 023 — TBD