Does Claude Code Remember Between Sessions? What Persists, and What Starts Fresh

Close the terminal, open it again, and type a follow-up question about the thing you were just building. Does Claude Code remember? The honest answer is: partly, and the part that persists is probably not the part you were counting on.

Every Claude Code session starts fresh. A new terminal window is a new session with its own context window. The conversation you had in the last one is gone as active context. That is deliberate: it keeps behavior predictable and prevents one session's assumptions from polluting the next. But it means Claude Code's "memory" between sessions is not one system. It is two separate mechanisms plus a gap, and knowing which is which saves you from trusting the wrong one.

The two things that carry over

1. CLAUDE.md: instructions you write.

CLAUDE.md is the primary persistence mechanism, and it is yours to maintain. Claude Code loads it at the start of every session: the project-level file in your repo, your global one in ~/.claude/, and files in subfolders when Claude works inside them. The fastest way to start one is /init, which generates a draft from your codebase, and typing # followed by text mid-session saves it straight into the most relevant CLAUDE.md for next time. Since version 2.1.277, Claude Code also reads a repo's AGENTS.md when no CLAUDE.md exists, so projects already set up for other coding agents work without a second file.

Think of CLAUDE.md as standing instructions, not memory. Build commands, conventions, project layout, auth patterns: the stuff that should be true every session. If a rule would be costly to lose, write it there.

2. Auto memory: notes Claude writes.

Separately, Claude Code maintains auto memory: notes it writes for itself about your preferences, corrections you gave, and ongoing work. These live on your machine in ~/.claude/projects/<project>/memory/. At session start, Claude loads the first 200 lines or 25KB of MEMORY.md, then pulls in topic files when it needs them. Run /memory to open these files or turn the feature off, and /context to see exactly what loaded into the current session.

Auto memory is learned patterns, not a record of your work. It captures "correct me the same way I corrected you last time" level knowledge. It does not store your conversations.

The gap: the session itself does not persist

Here is where people get surprised. When a session gets long, Claude Code compacts it: older conversation history gets summarized into a condensed form so the session can continue. That summary belongs to that session. The next session does not receive it. Session history is saved on disk for reference, but active context never carries over.

That gap is widest where automation operators live: scheduled runs. A Claude Code scheduled task starts a fresh session every time it fires. It reads the prompt file, runs against the working directory, and stops. Whatever it learned in the last run is gone unless the operator built state files for the agent to read at the start and rewrite at the end of each run. That works, but it is DIY persistence: you designed the schema, you handle the crash mid-write that leaves a half-updated state file, and you maintain it forever.

Three more limits worth knowing:

• Memory is per-machine. Auto memory lives in a folder on the machine where the session ran. Work on a second machine, or hand the project to a teammate, and none of it follows.
• Memory is per-tool. What Claude Code learns about you does not reach your Codex sessions, your Cursor chats, or your scheduled automations in n8n or Make. Each tool starts from zero.
• Nothing retrieves. Nothing searches your old sessions for what matters to the prompt in front of you. The files load in full or they do not load; there is no semantic search over past work deciding which pieces of context the current session actually needs.

What a real memory layer looks like

If you run scheduled Claude Code agents, the question stops being "does it remember" and becomes "where does the memory live." The built-in answer is: in files on your laptop, loaded in full, in one tool. That is fine for rules and learned patterns. It is not a shared memory.

A hosted memory layer takes the other job: continuity across sessions, machines, and tools. Vilix AI is cloud-hosted, so you manage zero infrastructure, and the same memory follows you over MCP into Claude, Codex, Cursor, OpenClaw, Hermes, and any other MCP-compatible AI. You save with save_turn and load with get_context, and retrieval is semantic plus keyword search, so recall finds what you meant, not just what you typed.

The difference that matters for scheduled runs: Vilix AI stores full conversation history, not just facts. A scheduled Claude Code task can wake up, pull what its previous runs actually did and said, and continue the work instead of re-briefing itself from a state file you hand-maintain. And because it is one account behind every connected client, a correction made in one tool is visible in all of them: last write wins, recency-aware retrieval, one place to fix.

The short version

Does Claude Code remember between sessions? Its rules do, if you wrote them down in CLAUDE.md. Its learned patterns do, on that one machine, in auto memory. Its sessions do not, and neither does anything across tools or machines. Use CLAUDE.md for durable instructions. Let auto memory carry repeated feedback. And if your agents need to remember actual work across runs and machines, put a hosted memory layer underneath them.

Get Started for Free (vilix.ai) Free forever, no credit card. Vilix AI also comes with a 7-day Pro trial, and you can export or delete everything anytime.