Claude Code Memory: How to Make It Persist Across Sessions

Every time you open Claude Code, it starts with zero knowledge of your project. No memory of the architecture decisions you made yesterday. No knowledge of the patterns you agreed on last week. No record of the bug you spent three hours fixing on Tuesday. Every session, from zero.

This is not a bug. It is how large language models work by default. The context window is cleared between sessions. Claude Code has no persistent storage layer unless you build one.

The Problem in Practice

Say you are building a SaaS product. In session one, you decide to use Drizzle ORM instead of Prisma — your specific reason being that Drizzle's type inference works better with your multi-tenant schema. You explain this to Claude Code. It understands. You make progress.

Session two. You ask Claude Code to add a new table. It suggests using Prisma. You have to explain the decision again. This happens for every architectural choice, every naming convention, every project-specific constraint you have established.

After a week of development, you are spending 15–20% of every session re-educating Claude Code about your own project. That compounds across a team. Each developer re-explains the same context independently.

What Native Claude Code Offers

Claude Code does have a few built-in mechanisms that partially address this:

CLAUDE.md files — you can write a markdown file at the root of your project and Claude Code reads it at session start. This is useful for high-level project rules. The limitation is that it is a static file. It does not capture decisions made during work, and it requires manual maintenance.

The context window — within a single session, Claude Code remembers everything. The window is large enough for most tasks. The problem is that everything vanishes when the session ends.

Conversation compaction — Claude Code can summarise older conversation turns to fit more into the context window. This helps within long sessions but does not help across sessions.

None of these give you genuine cross-session memory. You need a separate layer for that.

How Persistent Memory Works

A proper memory layer for Claude Code needs five things:

1. Captureautomatically record decisions, patterns, and fixes as they happen — not requiring you to manually log them
2. Storepersist to a local database that survives session restarts
3. Indextag memories to the git branch and commit they belong to, so context is project-aware
4. Retrievesurface relevant memories before each tool call, not by dumping everything into the context
5. Injectattach retrieved memories to the prompt automatically, so you never need to re-explain context

The retrieval step is the critical one most DIY approaches miss. If you inject all memories into every prompt, you waste context and reduce quality. Relevance scoring against the current task is what makes memory useful rather than noisy.

The SkillGod Solution

SkillGod implements all five steps using Claude Code's hook lifecycle. Here is how it works:

SessionStart hook loads your instinct rules and recent project memory before anything else. You start every session with context already loaded.

PreToolUse hook scores the current task against stored memories and injects the most relevant ones into the prompt. Only the top matches inject — not everything — which keeps the context clean.

PostToolUse hook captures what just happened. Decisions, patterns, errors. Async, so it does not slow down your flow.

Everything stores in a local SQLite database at ~/.skillgod/memory.db. Nothing goes to any server. Memories are tagged to git branch and commit, so context stays accurate as your project evolves.

The result: you explain architecture decisions once. SkillGod remembers them. Every session starts where the last one ended.

Memory Kinds

SkillGod captures four kinds of memory:

Install in 60 Seconds

Free tier includes persistent memory, all 9 CLI commands, git-aware session tracking, and 30 starter skills. No account required.