Does Claude Agent SDK Remember Between Sessions?

Partly. A Claude Agent SDK agent keeps the conversation from one session if you resume it, because the SDK writes that session's transcript to disk. A brand-new session starts without that history, and the SDK does not search across sessions, remember a user across unrelated sessions, or carry state to another machine on its own.

That distinction matters most when you ship an agent. In development, resuming the same session feels like memory. In production, your agent meets returning users and restarts on new machines, and each case crosses a boundary a single transcript does not cross on its own.

What does the SDK save during a session?

A session is the conversation history the SDK accumulates while your agent works: your prompt, every tool call, every tool result, and every response. The SDK writes it to disk automatically, as transcript files under the local Claude projects directory, so you can return to it later.

By default, each query call starts a new session, and the first message carries a session ID. If you do not capture that ID, or use the SDK's built-in continuation, the next call has no link back to the first one.

What happens when you resume a session?

Resuming restores the whole conversation, including tool results and reasoning, from the point where it stopped. In Python, capture the session ID from the first call and pass it back as resume later; with the Python client object, each query on the same client continues the same session automatically. In TypeScript, passing continue: true on a later query picks up the most recent session in the current directory.

Forking is the third option: a new session from a copy of an existing session's history, so you can try a different approach without losing the original. After the fork, the branches work independently.

Resume has a sharp edge. Tool results can go stale. If files changed since the earlier session, the resumed agent still sees the old tool results in its transcript. When that risk matters, start a new session with a short summary, or tell the resumed agent exactly which files changed so it re-reads them.

What does a new session not know?

A new session knows only what you pass into it. It does not search earlier sessions or pull up what a different session learned, and it does not know a returning user unless you load that user's context yourself.

That is the gap that trips up shipped agents. A customer support agent built with the SDK can hold a long, coherent conversation on Tuesday. On Wednesday, a new session for the same customer starts with no record of Tuesday's conversation, the workaround that fixed the problem, or the preference the customer stated. Nothing failed. The SDK simply stored one conversation, not a memory of the customer. The same gap shows up for scheduled work: a fresh run for a new task does not inherit what last night's run decided.

What about a different machine, a CI runner, or a serverless function?

Session files are local to the machine that created them. A session created on your laptop does not automatically exist on a CI runner or a serverless function.

The SDK offers a bridge: a session store adapter that mirrors transcript entries to your own backend, such as an object store or a database, so a session created on one host can be resumed on another host running from a matching working directory. The store, its availability, and its cleanup are yours to run.

What is the difference between a session and memory?

A session is one conversation's transcript. Memory is what an agent knows across conversations: a user's preferences, a project's decisions, and open items, searchable when relevant and updatable when facts change.

Session resume gives you the first, not the second. Resuming replays a transcript. It does not let the agent ask, "What do we already know about this customer?" across dozens of earlier sessions.

There is a related trap after a crash. The SDK persists the conversation, not the execution position inside the agent's loop. Resuming picks up the thread, but it does not guarantee the agent knows whether a tool call actually completed. A resumed agent can re-run a step that already happened.

How do you give a shipped agent memory that lasts?

Work through these steps in order, and stop at the first one that fits the agent you are shipping.

1. Capture the session ID for any conversation you will need to continue, and resume it deliberately.
2. For work that must survive a host change, add a session store adapter and test resume from a second host.
3. For preferences and decisions that must survive across unrelated sessions, store them outside the transcript: facts keyed to the user or project, loaded at session start and updated at session end.
4. For an agent that also runs in other tools, or a fleet of agents that should share what they learn, put that memory in a layer outside any single SDK session. A built agent connects to Vilix AI with an API key as a Bearer token to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure to run. Retrieval is semantic as well as keyword-based, so it finds what was meant, not just what was typed.
5. Test the boundary before you ship. Tell the agent a checkable fact in one session, end that session completely, start a fresh session, and ask about the fact. If it answers correctly, something in your setup carried it across.

Frequently asked questions

Does the Claude Agent SDK remember a conversation after a restart?

Yes, if you resume the session that holds that conversation. The SDK writes transcripts to disk, so a restart on the same machine does not erase them. A new session, or a session on a different machine without a session store, does not have that history.

Does resuming a session remember the user?

It remembers that one conversation, not the user. A resumed session knows what was said in that session. It does not search other sessions for the same user.

Is a session store the same as agent memory?

No. A session store mirrors transcripts so another host can resume the same conversation. Agent memory is a searchable store of facts, preferences, and decisions across conversations.

When is session resume enough?

When one long task spans several sittings, the files have not changed much, and nothing from other sessions needs to be consulted. For returning users, scheduled runs that must build on each other, or agents on many hosts, add a memory layer outside the session.

The short answer

The Claude Agent SDK remembers one conversation well, if you resume it. It does not remember a user, a project, or a fleet of runs across sessions on its own. Resume sessions deliberately, add a session store for other hosts, and put cross-session knowledge in a memory layer that outlives any single session.

Learn more about shared agent memory at https://vilix.ai/?utm_source=vilix-blog&utm_medium=article&utm_campaign=icp1-visibility