Practical guides to AI coding memory
What should you ask AI to remember?
Save a private memory when the context is durable, hard to reconstruct, and likely to help again. Keep temporary task state and facts that current source files can answer in their original tools. Never save secrets; be selective with another person's private information.
Use a return test
Before saving a note, ask whether you will need it after this conversation, whether it is difficult to look up again, and whether remembering it would change a future decision. A durable preference or the reason behind an ongoing decision often passes. A test result from this morning usually does not.
Keep the note narrow. Name who or what it applies to, when a decision was made, and the source or condition that would make you check it again. A source receipt helps you verify its source; it does not certify the note.
Separate what is useful from what is temporary
1. Long-term personal preferences
A preference such as “run a focused test before a broad refactor” can help across projects. Keep it in personal scope if it should follow your account, and update it when your working style changes.
2. Decisions with a date and reason
Record a decision only when its rationale will matter later. Include its date, intended project scope, accountable person or source, and a review condition. Keep the maintained decision record as the canonical project history.
3. Short-lived task state
A branch name, the test that just failed, or the next command is useful for the current task but often expires quickly. Put it in the issue, draft, or active work log that owns the task.
4. Facts a program can read
Versions, available scripts, feature flags, and current configuration belong in maintained files such as
package.json, CI settings, or application config. Check those files instead of relying on a remembered copy.5. Secrets and other people's private data
Do not store passwords, API keys, access tokens, or private conversation dumps. Avoid another person's confidential or identifying information unless you have permission and a clear need; keep any permitted note minimal.
Write a memory you can re-check
Prefer one claim with its scope and reason over a broad profile. For a decision, say when it was made and what source or later event would make you revisit it. For a personal preference, say whether it applies to all projects or one context.
Cairn's recall_memory result may include a source receipt; forget_memory takes the exact id from a recall result. Recall can miss a match. A receipt tells where the note came from, not whether it remains true. Check the maintained source before acting.
If automatic capture is enabled
The connected Claude Code plugin can capture conversation text automatically after setup. Ordinary text you paste into a conversation, including terminal output and file contents, can be included; credential masking is best-effort. Do not put secrets or a private transcript into a connected chat just because you expect memory to be selective.
Limits to keep in mind
- Recall is a search and can miss a relevant note. A returned source receipt does not validate the current state of code or a team's decision.
- Dates and review conditions in note text help a person judge context; they are not evidence that the choice remains active.
- Memory is private to its owner. It does not replace a shared, reviewed project record or become a team Knowledge Card by itself.