Why does my AI agent forget everything between sessions?

Your AI agent forgets everything between sessions because the model itself stores nothing. It does not learn from your conversation, and it writes nothing back to itself when the session ends. Everything it appeared to know lived in the context window. That window is a block of text assembled fresh for each request: your prompt, the files it read, and the transcript so far.

So the next session does not resume where the last one stopped. It starts from what your tools load by default: your repository, your instruction files, and the first message you type. The agent can reread the code. It cannot reread the reasoning that produced the code.

The facts are recoverable. The decisions, the rejected options, and the reasons are not.

What survives, and what gets loaded

Most coding agents do write the transcript to disk. Claude Code stores each session under ~/.claude/projects/, and claude --resume loads one back. Codex CLI and Gemini CLI keep their own local session history. The bytes survive.

What does not survive is availability. That transcript helps only if you resume that exact session, in that tool, on that machine. It is also a wall of tool calls and file dumps, not prose you can skim.

Loaded into the next session by default	Not loaded unless you go and get it
Files the agent wrote or edited	The previous transcript, even though the tool saved it
Instruction files like CLAUDE.md, AGENTS.md, GEMINI.md	The reasoning behind each change
Git history and commit messages	Approaches tried and abandoned
Anything a tool wrote to a known location	Constraints you explained in chat

The agent has the output of the previous work and none of its context. It will happily propose the approach you ruled out on Tuesday, because from where it sits, nobody ever ruled it out.

Bigger context windows do not solve this

A larger context window is a bigger desk, not a filing cabinet. It lets the agent hold more at once inside one session, which genuinely helps on a large refactor. It carries nothing across the boundary, because the tool rebuilds the window every time.

Long contexts also degrade inside a single session. As the transcript grows, the constraint you stated at the top competes with thousands of lines of file listings and test output. Agents lose the thread in long sessions, much as people do when a meeting runs three hours.

Compaction and summaries are not memory

Claude Code, Codex, and Gemini CLI all compact the conversation when it grows too long. The tool summarizes the transcript, replaces it with the summary, and keeps the session alive. That is lossy compression chosen by a machine that does not know which detail you will want next week.

Compaction serves only the session it happens in. It is not a record anyone would choose to read back a month later.

Write decisions down where the next session will look

The durable fix has three parts. Decide what deserves to outlive the session: decisions and their reasons, facts that were expensive to discover, and open follow-ups. Write those to plain files in a known location. Then make reading them the first thing the next session does.

You can do this today with no new tools. Create docs/decisions.md and append an entry whenever something is settled:

## 2026-08-30 Billing retries use exponential backoff
Fixed windows caused a thundering herd against the payments API.
Rejected: a flat 30s retry, and a queue-based retry service.
Open: jitter is not implemented yet.

Then add the recall step to the instruction file your agent already reads: CLAUDE.md for Claude Code, AGENTS.md for Codex, GEMINI.md for Gemini CLI:

Before proposing an approach, read docs/decisions.md and say which entries apply.
After a decision is settled, append an entry: date, decision, reason, rejected
options.

For one repository that is often enough. Markdown diffs cleanly in git, you can read it without a tool, and any agent with filesystem access can open it.

People underestimate the recall step. A memory file nobody reads at the start of a session is a diary. The habit that makes this work is recall before the agent proposes, not after it writes the code.

Three things eventually strain that single file. It grows, until reading all of it every session is back to loading irrelevant context. Decisions that are not about code have nowhere to live. And each tool wants its instructions in a different file.

Doing this with the Jotura CLI

Jotura is a local-first markdown notes app, and a first-party command-line tool called jotura ships with it. Agents use that CLI against the same vault of plain .md files you edit in the app. It runs on Mac, Windows, and Linux, with an Android app. There is no iOS app.

Jotura itself is closed source. The vault is not. It is an ordinary folder of .md files that any tool can read, grep, and commit, so nothing you store is trapped if you stop using the app.

At the start of a task, the agent pulls a digest of what is known:

jotura context "refactor the billing retry logic"

Before proposing an approach, it recalls prior decisions on the topic, ranked rather than loaded whole:

jotura memory recall "billing retries"

When something is settled, it records the outcome with a kind, so a later recall can tell a decision from a loose fact:

jotura memory log --kind decision \
  --title "Billing retries use exponential backoff" \
  --body "Fixed windows caused a thundering herd against the payments API."
jotura memory log --kind followup --title "Backoff jitter is not implemented yet"

Ordinary note edits go through hash-checked writes, so two agents working at once cannot silently overwrite each other. The agent captures the file’s hash on read and passes it back on the write, and a file that changed in between fails the edit instead of losing the change:

HASH=$(jotura read "Projects/Billing/Decisions.md" --json | jq -r .hash)
jotura edit "Projects/Billing/Decisions.md" \
  --replace "Status: draft" --with "Status: approved" --if-hash "$HASH"

The --replace flag requires a unique match by default and errors on ambiguity rather than guessing. Writes are atomic, and body edits never touch a note’s YAML frontmatter, the metadata block at the top of the file. The CLI page covers the rest of the command surface.

Keeping the instructions in one place

Memory is half the problem. The other half is instructions drifting apart across tools. Jotura keeps an Agents/ folder in the vault as the canonical copy and reconciles it with each tool’s expected location:

jotura agents status
jotura agents sync

Sync runs in both directions. It pulls system-side edits into the vault and applies vault edits to the system, comparing both against the last synced state. If you changed the vault copy and the system file between runs, that file is skipped rather than merged, and you pick a winner with --prefer vault or --prefer system.

That covers Claude Code’s CLAUDE.md and skills, Codex’s AGENTS.md, Gemini’s GEMINI.md, and Copilot instructions. For a step-by-step version, see give AI agents persistent memory.

What this does not fix

There are limits worth stating. This gives an agent a place to remember, not the instinct to use it. If your instruction files do not tell it to recall before proposing and log after deciding, it will not.

It also does not restore the sessions you have already lost. Memory built this way starts empty. The first few entries do nothing. It pays off the first time an agent quotes back a decision you had forgotten making.

Frequently asked questions

Does a Model Context Protocol (MCP) memory server solve this instead? It can, and several do. A server ranks and filters memories in ways a flat file cannot, any client that speaks the protocol reaches it without a local vault, and there is no per-tool config to keep in step. Files win when you want to read, grep, diff, and review the memory yourself. That comparison is worked through in MCP memory servers versus plain markdown files.

Can I just put everything in CLAUDE.md? For a small project, yes. It stops scaling past a few hundred lines, because everything in that file loads every session whether it is relevant or not. Recall on demand keeps the always-loaded file short.

Do I need paid sync for this? No. Everything above works on one machine with local files and no account. Jotura Sync costs £4 a month or £40 a year and carries the same vault between your computers with end-to-end encryption. There is no free trial.

Will this work with more than one agent? Any agent that can run a shell command reads the same vault, and the config for Claude Code, Codex, Gemini, and Copilot syncs from one folder. That is the point of shared memory across AI coding agents.