Claude Code Sessions vs. Context: Why It Remembers Things You Deleted

A while back I noticed my Claude Code project folder had quietly grown to about 111 saved sessions eating roughly 660 MB of disk. So I cleaned them up. Deleted the lot, kept the current one, moved on with my life.

Then, a few days later, a brand-new session casually referenced a defect from a conversation I had deleted. Something like:

DEF-2210 was previously related to…

Hold on. This was a fresh session. The transcript that discussed that bug was gone. How did it know?

That little moment of suspicion sent me down a rabbit hole, and what I found is the most useful mental model I’ve built about Claude Code so far: a saved session and the active context of a new conversation are not the same thing. Old sessions may sit on disk so /resume can reopen them, but that doesn’t mean Claude reads all those old transcripts every time you start fresh.

Think of it like an office. You might have 111 old case folders sitting in a filing cabinet. Starting a new meeting doesn’t mean somebody dumps all 111 folders onto the conference table. The folders still exist, and /resume lets you pick one and reopen it, but they are not automatically part of the new conversation.

Let me walk through what’s actually going on.

The three layers of Claude Code: saved conversation history sits on disk like folders in a filing cabinet (not auto-loaded, reachable via /resume); persistent project knowledge — memory, CLAUDE.md, hooks — shapes every session; and the active context is what Claude is actually working with right now.

What a saved session actually is

Every conversation gets stored under a project-specific directory, something like:

~/.claude/projects/-Users-alex-code-startups-NimbusCRM/

Inside that directory, each conversation has a UUID, something like:

7f3a2c91-4e8d-4b6a-9f21-0c5d8e7a1b42

The main conversation is stored as a .jsonl file:

7f3a2c91-4e8d-4b6a-9f21-0c5d8e7a1b42.jsonl

JSONL means JSON Lines. Instead of storing the whole conversation as one enormous JSON object, the file contains a sequence of records. Those records represent my messages, Claude’s responses, tool calls, tool results, and other session events.

A simplified transcript conceptually looks like this:

user message
       ↓
Claude response
       ↓
tool invocation
       ↓
tool result
       ↓
Claude response
       ↓
user message
       ↓
...

Some sessions also have a directory associated with the UUID. That directory can hold supporting material such as attachments, tool artifacts, or subagent conversation data.

So when I had about 111 sessions consuming roughly 660 MB, most of that space was historical conversation records and their associated data, kept around so Claude Code could restore those conversations later.

What /resume is doing

The /resume command is essentially a way of saying:

Show me previously saved Claude Code conversations that I could continue.

Claude Code looks at the saved session files and presents them for selection. Pick one, and it reconstructs that earlier conversation. So /resume is directly tied to the transcript files on disk.

Before my cleanup, the situation was approximately:

Claude project storage
│
├── session-A.jsonl
├── session-B.jsonl
├── session-C.jsonl
├── ...
├── session-111.jsonl
│
└── memory/

After the cleanup, the old session transcripts were removed while the current session and memory remained:

Claude project storage
│
├── 7f3a2c91-...jsonl      ← current conversation
│
└── memory/                ← deliberately preserved

Which is why /resume no longer shows me those 110 deleted conversations.

But why did a brand-new session still know old things?

This is the part that triggered my original suspicion, and it turns out the distinction really matters.

There are two very different mechanisms at play:

OLD TRANSCRIPTS                    PERSISTENT PROJECT INFORMATION

session-A.jsonl                    memory/MEMORY.md
session-B.jsonl                    CLAUDE.md
session-C.jsonl                    hooks
session-D.jsonl                    configuration/instructions
      │                                  │
      │                                  │
   /resume                         new sessions may receive these

Deleting the left side does not delete the right side.

The key player here is memory/MEMORY.md. It holds distilled facts accumulated from previous work — past defects, incidents, project decisions, preferences. That’s how a completely new conversation can still say:

DEF-2210 was previously related to…

My first reaction was, “How does it know that? This is a new session.” But it never needed to read the old conversation. A fact extracted from that conversation had been saved into persistent memory long before I deleted the transcript.

Transcript versus memory

An example makes the difference obvious.

Suppose an earlier session contained 40,000 words discussing a production outage. Somewhere in that conversation, the important conclusion emerged:

Production outage:
Missing database migration caused authenticated requests to fail.

The entire 40,000-word transcript sits in:

abc123.jsonl

But memory only keeps the compressed fact:

NimbusCRM production incident:
authentication failure caused by unapplied database migration.

A new conversation does not need the full 40,000-word transcript to know that fact. It only needs the small memory entry.

This is why deleting transcripts and deleting memory accomplish two different things.

Deleting transcripts says:

"Do not retain these resumable conversations."

Deleting memory says:

"Do not carry these learned project facts into future sessions."

I chose the first operation and deliberately did not choose the second.

CLAUDE.md is another source of apparent memory

Claude Code also reads instruction files like CLAUDE.md. These are not conversation transcripts. They’re closer to an employee handbook Claude receives whenever it works in a particular environment.

A project might contain instructions conceptually like:

# Project

This application is NimbusCRM.

Backend: TypeScript
Database: PostgreSQL
Deployment: Fly.io

Run tests before committing.
Never modify production data without approval.

You could delete every conversation Claude has ever had about that repository, and it would still know those facts in a fresh session, because they’re written down in CLAUDE.md.

Again, that’s not old conversation leakage. It’s deliberate project initialization.

SessionStart hooks can add still more information

The third mechanism is the SessionStart hook.

A hook is something that runs automatically when a particular event occurs. A SessionStart hook runs when Claude Code begins a session and can inject additional instructions or information.

Conceptually:

Start Claude Code
       │
       ├── Load applicable CLAUDE.md
       │
       ├── Load persistent memory
       │
       ├── Run SessionStart hooks
       │
       ↓
New conversation begins

So even though the conversation itself is new, the environment surrounding it can carry quite a lot of project knowledge.

What is the active context, then?

There’s another word worth separating from session: context.

The session is the continuing conversation and its saved history. The context is the information available to the model while producing a particular answer.

A simplified model:

ACTIVE CONTEXT
│
├── Claude/system instructions
├── applicable CLAUDE.md instructions
├── persistent memory supplied to Claude
├── hook-generated instructions
├── current conversation messages
├── relevant tool results
└── other information Claude Code injects

That bundle is what Claude reasons over.

So asking “Is this a new session?” and asking “Does Claude have previous project knowledge?” are not contradictory questions. Both answers can be yes.

New conversation?          YES

Old transcript loaded?     Normally no, unless resumed or otherwise retrieved.

Old project knowledge?     Possibly yes.

Why?                       Memory, CLAUDE.md, hooks, and other
                           intentionally supplied context.

What my cleanup actually accomplished

My cleanup command deleted all the old .jsonl conversation transcripts except the active session. It also removed the associated session directories while explicitly protecting the memory directory.

The critical protection was conceptually:

! -name 'memory'

That exclusion mattered. Without it, a careless recursive deletion of the whole project-state directory would have destroyed persistent project memory as well.

After the operation: roughly 110 old sessions removed, about 660 MB freed, current session and memory intact.

So I ended up with:

Historical /resume conversations     mostly gone
Persistent project memory            retained
CLAUDE.md                            retained
Hooks                                retained
Current conversation                 retained

What cleanupPeriodDays: 7 changes

To keep this from happening again, I added a setting to:

~/.claude/settings.json

with:

"cleanupPeriodDays": 7

The purpose of that setting is to stop old resumable sessions from accumulating indefinitely. Claude Code periodically prunes session history older than the configured retention period.

The important point: this is a session-retention policy, not a command to erase the project’s persistent memory.

Conceptually:

Day 1   Session A
Day 2   Session B
Day 3   Session C
...
Day 8   older session becomes cleanup-eligible

So instead of eventually crawling back to another pile of 111 historical sessions, my /resume history should stay manageable on its own.

The mental model to remember

The cleanest way I’ve found to think about Claude Code is three layers.

┌──────────────────────────────────────┐
│  CURRENT CONTEXT                     │
│  What Claude can work with now       │
│                                      │
│  instructions + memory + messages    │
└───────────────────▲──────────────────┘
                    │
                    │ initialized from
                    │
┌──────────────────────────────────────┐
│  PERSISTENT PROJECT KNOWLEDGE        │
│                                      │
│  memory/                             │
│  CLAUDE.md                           │
│  hooks/configuration                 │
└──────────────────────────────────────┘


┌──────────────────────────────────────┐
│  SAVED CONVERSATION HISTORY          │
│                                      │
│  UUID.jsonl                          │
│  UUID/ attachments/subagents         │
│                                      │
│  primarily used for /resume          │
└──────────────────────────────────────┘

The bottom box is what I cleaned. The middle box is what I deliberately kept. The top box is constructed fresh every time Claude actually works.

So my original suspicion was partly right, just not for the reason I assumed. A new Claude Code session really can appear to carry knowledge from old work. But that knowledge travels through persistent memory, CLAUDE.md, hooks, and other startup context — not because Claude stuffs all 111 old .jsonl transcripts into every fresh context window.

That distinction is the whole takeaway: deleting /resume history makes conversations non-resumable; it does not make Claude forget the project.