Claude Code Memory: Native Features and the Supermemory Plugin

Claude Code already has persistent context mechanisms: CLAUDE.md files for written project instructions and auto memory for learned notes. An external memory plugin is an additional option when you need another way to capture, organize, or retrieve context across coding sessions. Start by understanding what the native features already retain.

The practical question is where a particular fact belongs. Build commands belong in maintained repository instructions. The reason a migration avoided a certain approach may belong in an architecture decision record. Temporary debugging state needs a clear scope and an expiry or correction path.

Native memory and an external plugin serve different needs

Mechanism	Good use	Check before relying on it
CLAUDE.md and scoped rules	Team conventions and known workflows	Correct file scope, conflicting rules, and stale instructions
Claude Code auto memory	Useful learnings and preferences	What was saved and whether it applies to this repository
Versioned project documents	Reviewed architecture decisions	Source revision and whether the decision is still active
Supermemory plugin	Additional capture and retrieval across sessions	Authentication, project scope, capture settings, and retrieval behavior

Anthropic documents native memory and its management commands. These files provide context; they are not a substitute for enforcement of access controls or release rules.

Diagnose the missing context before installing more tools

When an assistant repeats a rejected approach, locate the decision first. If it exists only in an old conversation, write a concise record with the rationale and source. If it exists in a project file, check whether the current session loaded or retrieved that file. If the file is loaded, inspect whether contradictory instructions or an outdated summary compete with it.

For a large repository, avoid pasting the whole codebase into memory. Keep durable architectural facts and references, then inspect current source when implementation details matter. A remembered function signature can become stale after a refactor.

The existing SMFS engineering article explores a filesystem-oriented retrieval approach. It is useful background when deciding how an assistant should find relevant files in a large repository.

Install and verify the Supermemory plugin

The current plugin documentation specifies Node.js 18 or later and these commands inside Claude Code:

/plugin marketplace add supermemoryai/claude-supermemory
/plugin install supermemory

Configure the documented SUPERMEMORY_CC_API_KEY through your local credential mechanism, restart the relevant session if needed, and check:

/supermemory:status
/supermemory:project-config

Keep keys out of committed repository files. If you have the older plugin name installed, use the migration instructions in the same documentation rather than assuming it updates in place.

The documented plugin provides recall decisions, capture, and separate project and personal scope controls. Inspect those settings before indexing a repository or enabling capture of work conversations. After setup, run the two-session test below to check authentication and recall for your project.

Give project decisions enough context to survive reuse

A useful record includes the decision, the reason, the repository or project, and the source revision. For example:

Project: billing-worker
Decision: keep invoice reconciliation in the existing queue worker.
Reason: the rollout must preserve the current retry and audit path.
Source: architecture/adr-014.md at revision abc123.
Revisit when: the new queue has passed the replay test.
Status: accepted for the current migration.

This example is fictional. Its value is the structure: the assistant can recover the rationale without interpreting an old preference as a permanent constraint. After the queue changes, update the record and its source rather than accumulating contradictory “remember this” notes.

Separate personal style preferences from team decisions. “I prefer compact comments” may belong to one developer. “All releases require migration replay checks” belongs to the team's maintained workflow. A shared memory scope should not silently mix the two.

Run a two-session acceptance test

Use a harmless fictional decision in a disposable project. Save it through the configured mechanism, close the conversation, and start another session for the same project. Ask a question whose answer depends on that decision and inspect the evidence retrieved.

Then test a different project, a corrected decision, and a question that does not require memory. Confirm that the old decision is not applied globally and that an irrelevant memory does not distort the answer. Record whether the evidence came from native files, auto memory, the plugin, or a direct source read.

Add one test after a source-code change. The assistant should inspect the current implementation before asserting that an old file path or API still exists. Memory should shorten the search for context, not exempt the agent from checking current code.

Compare plugins using your repository workload

Evaluate whether you can inspect captured content, control scope, correct records, and understand what gets sent to a hosted service. Measure retrieval relevance and context overhead on the same tasks. A benchmark for general conversational recall is not a benchmark for navigating your repository.

A remote MCP connection exposes tools to a client; a plugin can add client-specific behavior. Neither label alone proves exactly when information is saved or recalled.

Begin with one repeated failure, such as forgetting why a dependency was rejected. Make its source and scope explicit, test recovery in a new session, and expand only after that works reliably. For OpenClaw-specific behavior, use the existing OpenClaw article rather than assuming Claude Code instructions transfer unchanged.

Try this on a recurring repository task: set up the Supermemory Claude Code plugin, save a fictional project decision, and check whether a fresh session can recover it in the right scope. Use that result to decide where the plugin adds value alongside native memory.