How to see what your AI agent remembers

To see what your AI agent remembers, open the files it reads. Almost everything a coding agent carries from one session to the next is plain text sitting on your disk. There are three surfaces: instruction files loaded at the start of every session, a per-project memory directory the agent writes to itself, and whatever memory store you added on top.

For Claude Code those are ~/.claude/CLAUDE.md, any CLAUDE.md in the project you are working in, and ~/.claude/projects/<project-slug>/memory/. The slug is your working directory path with the separators replaced by dashes. Codex reads ~/.codex/AGENTS.md, Gemini CLI reads ~/.gemini/GEMINI.md, and GitHub Copilot reads ~/.copilot/copilot-instructions.md plus a repository-scoped instructions file.

Two things fall outside that. A hosted memory feature keeps its record on someone else’s servers, so your audit is limited to whatever interface the product offers. A store backed by embeddings can be queried but not read straight through, because a list of vectors is not a document. Everything else is a file, and files are the easy case.

Start with the agent’s own memory command

Most runtimes ship a command for this, and it resolves the loaded set for you. In Claude Code, /memory lists the memory files in effect for the current session and opens them for editing. Gemini CLI has /memory show.

One behavior matters before you audit anything. In Claude Code, starting a line with # during a session appends it to a memory file. Instructions arrive that way without a deliberate edit, which is the usual answer to “where did this even come from”.

Then read the files directly

Reading the files is what lets you diff them, script against them, or keep them in version control.

cat ~/.claude/CLAUDE.md
ls ~/.claude/skills/ ~/.claude/agents/
cat ./CLAUDE.md
ls ./.claude/skills/ ./.claude/agents/
ls ~/.claude/projects/<project-slug>/memory/

Two mechanisms mean the file you print is not the whole set that loads. An instruction file can reference other files, so what the agent sees is a tree rather than one document. Project instruction files are also picked up from your working directory and its parents, so a CLAUDE.md two levels up loads without ever appearing in cat ./CLAUDE.md. Walk up the tree, or trust the in-tool view.

If you keep agent configuration in a Jotura vault, the vault copy is canonical and the system locations are generated from it:

Vault file	System location
Agents/Claude/CLAUDE.md	~/.claude/CLAUDE.md
Agents/Claude/Skills/<name>/	~/.claude/skills/<name>/
Agents/Claude/Subagents/<name>.md	~/.claude/agents/<name>.md
Agents/Codex/AGENTS.md	~/.codex/AGENTS.md
Agents/Gemini/GEMINI.md	~/.gemini/GEMINI.md
Agents/Copilot/copilot-instructions.md	~/.copilot/copilot-instructions.md

Every path on the right is a global personal file. Copilot’s repository instructions live in the repository instead, so audit those per repo. One command then tells you whether the copy you reviewed is the copy your agent is actually loading:

jotura agents status --json

That is a read-only drift report. It never writes anything, and it always exits 0. A difference on one side is a memory you thought you had edited and had not.

Read the memory store itself

Instruction files hold your standing rules. The accumulated record is the more interesting audit: decisions the agent made, facts it learned, follow-ups it opened.

The generic method works on any text-backed store. List the files, read the frontmatter or top heading of each, check the dates, and grep for the topics you care about. If your store is an MCP memory server, check its entry in your MCP configuration for the storage path. Many of them write to a plain JSON file you can open.

Jotura keeps each memory as an ordinary note under Memory/, or under any nested Memory/ folder if you split roots per project. Every file carries kind, status, importance, and date in its frontmatter.

jotura memory list
jotura memory list --kind decision --status active
jotura memory list --kind followup --status open
jotura read "Memory/Decisions/2026-02-03 use-redis-for-the-job-queue.md"

To see what the agent would surface for a topic rather than the whole archive, run a recall. It ranks by keyword relevance, freshness, and importance, which is the ranking the agent gets.

jotura memory recall "job queue"
jotura memory recall "job queue" --include-stale

Read the default carefully. Recall drops anything superseded, anything resolved, and any active memory older than about 180 days. Add --include-stale during an audit, because an old decision that is still wrong is exactly what the default hides. That cuts both ways: the agent does not see those memories either.

The four things worth looking for

An audit is not a proofread. You are looking for specific failure modes, and only a few matter.

Decisions that are no longer true. These are the expensive ones. An agent that still believes you chose Redis will keep writing Redis code. List anything active and old, then read the ones that look suspicious.

jotura memory list --stale

That returns active or open memories older than about 180 days.

Contradictions. Two active decisions pointing opposite ways produce inconsistent work, and the agent cannot tell which one you meant. Recall a topic and read the top results together rather than one at a time.

Follow-ups nobody closed. Open follow-ups accumulate quietly and start crowding out useful context. Filter for them, then close them or act on them.

Anything that should never have been written down. Credentials, tokens, customer data, private details about colleagues. Memory is a record of the work, not of the people doing it. Delete those files rather than superseding them.

Fix what the audit found

Deleting a wrong decision loses the history of why it was ever right, so prefer superseding. The move is the same in any store: write the new decision, mark the old one superseded, and link the two. Both stay readable, and anyone who finds the old one is told where to go next.

In Jotura that is three commands. memory log stamps the new note with today’s date and prints the path it created, so substitute that path into the supersede call.

jotura memory log --kind decision --title "Move the job queue to Postgres" \
  --project billing --body -
jotura memory supersede "Memory/Decisions/2026-02-03 use-redis-for-the-job-queue.md" \
  --by "Memory/Decisions/2026-08-30 move-the-job-queue-to-postgres.md"
jotura memory resolve "Memory/Followups/2026-03-11 confirm-queue-throughput.md"

--body - reads the reasoning from standard input. Without it, a decision note is created as four empty headings, and your next audit finds a decision with no stated reason.

Then check the result from the agent’s side. jotura context prints the pack an agent receives at the start of a session, the closest thing to seeing memory through the agent’s eyes. If your agent config has drifted since the last sync, that output says so too.

jotura context "job queue work"

What you still cannot see

Auditing files tells you what the agent can load. Session transcripts are on disk too: Claude Code writes each session to ~/.claude/projects/<project-slug>/<session-id>.jsonl, turn by turn, tool calls included. What no file records is the model’s internal weighing, so you cannot recover why it leaned on one memory and ignored another.

Hosted and embedding-backed stores are a real gap, and it is worth saying where they win first. Embedding-backed recall finds the right memory when your wording does not match the note’s wording, which is precisely where keyword search fails. Hosted memory needs no setup and follows you across devices with no sync product to buy. The tradeoff is that you audit search results rather than the record, and that comparison is worked through in vector database vs markdown for agent memory.

Where Jotura fits, and where it does not

Jotura is a free local-first markdown notes app for Mac, Windows, Linux, and Android, and the jotura CLI ships with it. Memory notes are plain .md files in an ordinary folder, so nothing is locked in a database only one program can read. Reading and searching them works with any editor or grep. What the CLI adds is ranking, status tracking, drift detection, and hash-checked writes.

The honest limits. There is no iOS app, no plugins, no graph view, and no publish-to-web. The app is closed source, so the audit trail you get is the file contents rather than the source code. Jotura Sync carries memory between machines with end-to-end encryption, costs £4 per month or £40 per year, and has no free trial.

Everything local is free. You can download it and audit an existing folder of markdown today. The CLI reference covers the full command surface, and give AI agents persistent memory covers setting a store up in the first place.

Common questions

Does my agent remember previous conversations by default? Not the conversations themselves. Most coding agents start fresh apart from the instruction files and memory directories they load. Anything else you want carried forward has to be written down, which is covered in why your AI agent forgets everything between sessions.

How often should I audit? Run jotura memory list --stale monthly, and read the active decisions for a project before starting significant work on it.

Can I audit an agent’s memory without installing anything? Yes, if the memory is text. cat, ls, and grep get you through an instruction file, a memory directory, and a folder of markdown notes.