When do I need an external memory tool instead of Claude Code auto memory?

Claude Code auto memory is enough when useful learning stays within Claude Code and one repository on your machine. Add external memory when the same private context must reach other assistants or machines, or you need a separate source-inspection workflow. Cross-project preferences alone do not require another service: user-level instructions can already cover them.

What does Claude Code's own memory do today?

The official memory documentation, accessed 2026-11-12, distinguishes instructions you maintain from notes Claude writes. Project instructions describe expected behavior. Auto memory keeps selected learning from interactions; it is not a recording of every conversation.

The current documentation describes auto memory as repository-scoped and shared across that repository's worktrees on the same machine. Its files are machine-local rather than automatically shared with another computer or cloud environment. Notes are organized under a memory directory with an index and separate topic files. You can inspect them rather than guessing what was saved.

Use CLAUDE.md or supported AGENTS.md instructions, .claude/rules/ for organized rules, and ~/.claude/CLAUDE.md for user-level instructions. Auto memory lives under ~/.claude/projects/<project>/memory/. Open /memory to inspect the memory settings.

The repository placeholder above is chosen by Claude Code; do not create a literal directory with angle brackets. Native loading behavior depends on your installed version and configuration, particularly when multiple instruction filenames coexist. Use the official page to check those details before reorganizing a working setup.

Auto memory is enabled by default in ordinary local sessions, with exceptions for some hosted or background contexts. The official page describes notes for user context, feedback, project context and outside references. At session start, the index is limited to its first 200 lines or 25KB, whichever comes first; detailed topic files can be read separately. Use the memory panel to inspect saved notes or change the auto memory setting.

Use the client's permission controls for actions that need technical enforcement. Memory notes guide behavior; permissions govern allowed operations.

When is auto memory already enough?

Suppose you work in one repository, use Claude Code there, and mostly want it to remember corrections about how you collaborate. You can inspect the saved notes, edit an inaccurate one, and continue working without adding authentication, another database or a second service.

The decision should start with the next reader. If that reader is another Claude Code session using the same repository's local memory, a separate cross-tool system may solve no problem you currently have. If the context is a stable rule for everyone who edits the repository, make it a maintained instruction instead of waiting for an assistant to infer it.

Personal instructions are another often overlooked option. A preference about explanation style can live in your user-level instruction file and apply across your Claude Code projects. Use that native option when the preference only needs to reach Claude Code.

Stay native when the existing behavior meets your need and you can explain where each important piece of context lives. Adding a store becomes worthwhile only when its reach or controls answer a specific gap.

Which gaps actually justify external memory?

The clearest gap is a different assistant. If you make a personal decision while working in Claude Code and need Codex or Cursor to retrieve it later, those clients need an agreed shared source. Connect each client to that source so it can retrieve the saved context.

A second gap is continuity between computers. You may work from a desktop and a laptop without wanting to copy personal memory directories manually. A hosted memory service can offer a common account-backed store, provided both installations connect to it. A self-managed local store can also be moved or backed up, with a transfer and backup process you manage.

A third gap is how you want to inspect a saved claim. A team may already maintain canonical decisions in version control while an individual wants a separate private reminder with the source excerpt that led to it. That is a different job from making every instruction file longer. Compare the available inspection, correction and deletion paths before adopting a tool for this reason.

Before installing, name the client that will use the saved context and check its supported connection. Then choose the storage location and inspection controls that fit that use.

Where does Cairn.ink Memory fit?

Cairn.ink Memory fits private context that should follow you between Claude Code, Codex and computers. A Memory is a private, user-owned fact, preference or decision. Its Source Receipt supplies the source excerpt and client metadata so you can inspect why it exists.

Start with the installer:

npx @cairn-ink/memory setup

Choose Cloud for automatic capture and prompt recall across Claude Code and Codex. The installer finds both CLIs; approve the connections, fully close both tools and wait for background work to finish before confirming. One browser sign-in connects a first paired installation, and a memory ID links the same project across tools. You can choose Cloud directly with:

npx @cairn-ink/memory setup --cloud
npx @cairn-ink/memory status

After reopening Codex, review the four Cairn hooks in /hooks. Hooks run at client session events and provide the automatic behavior. MCP, the Model Context Protocol, provides callable tools alongside them. This makes the cloud integration useful when you want context to carry over during ordinary work, including when you switch assistants.

Choose Local at the setup question for free, no-account use on one computer, or run:

npx @cairn-ink/memory setup --local

Local uses one SQLite database for supported clients and explicit tools, without automatic capture or cross-computer sync. Model-backed semantic recall can send selected text to your configured provider. See the release documentation and installer README for the mode-specific behavior.

For cloud controls, a paired installation can use:

npx @cairn-ink/memory pause
npx @cairn-ink/memory resume
npx @cairn-ink/memory prompt-recall-off --client codex
npx @cairn-ink/memory config --codex-daily-cap 300

Pause skips conversations rather than backfilling them later. Codex prompt-recall-off keeps capture running and leaves MCP available. The daily cap is a separate capture control: Codex defaults to 200 per day, existing installations keep their stored cap, and a change with an existing daily counter starts at the next daily reset. Claude's quota is independent.

Cloud saves conversations after best-effort local masking and sends a masked, length-limited prompt copy for recall. Review the privacy controls before enabling it. Private Memory stays separate from Knowledge Cards, whose review and publication follow their own human-authorized process.

How can I decide without moving all my notes?

Pick one recurring problem: perhaps a preference that you repeatedly explain to two assistants. Leave repository instructions and existing native notes where they are. Write down which client should save the preference, which client should retrieve it, and whether it is personal or project-specific.

Test with a harmless synthetic statement. Confirm a real save response, open a fresh session in the other client, and request retrieval without supplying the answer. Compare the saved identifier and source when the product provides them. If the second client only repeats something you pasted into its prompt, you have not tested shared memory.

Also test a change of mind. Check that the documented correction or forgetting path produces the behavior you expect, then query again. A system that can retrieve an old preference but leaves you unsure how to retire it has not yet passed your workflow test.

How do I keep two memory systems from disagreeing?

Assign each kind of context a clear home. Current runtime versions belong in maintained project files. Shared coding conventions belong in reviewed instructions. A private cross-tool preference can belong in a shared private memory store. Native learning can remain useful for local interaction details.

When two notes conflict, consult the current source and your present instruction. Remove or amend stale copies rather than asking the model to infer which one you intended. Compare a Source Receipt with the current source to resolve freshness or priority. For the worked service, hosted tools offer remembering, recalling and forgetting; the local tools additionally support correction. Do not assume the two surfaces expose identical commands.

For your next step, choose one preference that needs to follow you between assistants and test it with the connection guide.