Claude Memory vs CLAUDE.md: Facts, Rules, and Scope

Claude memory and CLAUDE.md serve different jobs: memory preserves selected context, while CLAUDE.md gives Claude Code explicit written instructions. Also distinguish Claude’s chat memory from Claude Code’s auto memory; the shared name does not make them one storage system. Choose by what the information means and who needs to review it.

A formatting rule, a useful preference, and today’s unfinished task need different upkeep. fenbs gives shared decisions and current work an explicit home outside either Claude mechanism, so another connected assistant can read the same record.

Which option fits each kind of information?

Anthropic’s Claude Code memory documentation↗ (opens in a new tab) distinguishes written instructions from notes Claude saves itself. Its separate chat memory help↗ (opens in a new tab) describes the controls for conversational memory. Check the documentation for the product you actually use.

Think of a small web project. “Use the existing button component” is a continuing instruction. “The client approved the shorter contact form” is a decision. “Delivery testing is still unfinished” is progress. Keeping all three in a single growing memory note makes it harder to tell what someone must do, what was agreed, and what remains uncertain.

What does a saved memory establish?

A saved memory tells you that some context was retained. It does not prove that a person approved the statement, that the information is current, or that the next answer will apply it correctly. Those are separate questions you should be able to answer before relying on it for work.

Suppose an assistant notes, “The client prefers brief updates.” That may be useful. It still needs interpretation: brief enough for a text message, or a one-page weekly report? If the distinction matters, turn the preference into a clear instruction after a person confirms it rather than letting an inference become a team rule.

Use a simple review: read the saved wording, identify where the fact came from, and ask whether it still changes the next action. Correct a stale entry directly instead of adding another contradictory sentence. A memory collection becomes harder to trust when old and new answers remain equally visible.

For conversational project context, the Claude project memory guide explains the separate scope question. This comparison is about deciding what belongs in each record, rather than configuring every memory setting.

When should an instruction be written explicitly?

Write an instruction explicitly when someone needs to inspect its exact wording and maintain it deliberately. A rule such as “Run the project’s documented checks before reporting a change complete” should not depend on whether an assistant happens to infer it from a correction in chat.

Keep each instruction actionable. “Keep the interface consistent” asks the assistant to guess. “Use the existing button component and preserve its accessible label” gives it something concrete to follow and a reviewer something concrete to check. Add a short reason when the rule would otherwise look arbitrary.

CLAUDE.md is a natural place for stable instructions within Claude Code. Anthropic notes that it is context, not an enforced control. Real access restrictions need the relevant tool or service settings; a sentence in a file does not replace them.

Leave detailed file placement to the CLAUDE.md location guide. For wording patterns, see the existing CLAUDE.md examples. The decision here is whether the statement is an instruction worth maintaining, not which directory wins a loading conflict.

How do scope and sharing change the choice?

Ask who should know the information. A personal preference can stay personal. A project rule needs to reach everyone doing that work. A company decision may matter to a designer in a chat app and a developer in a coding tool, even though only one of them ever opens the repository.

In Claude Code, auto memory is machine-local; project CLAUDE.md instructions can be shared through source control, the system teams use to review file changes. This difference matters when a teammate starts on another computer. Do not assume that something one assistant remembered is now part of the team’s shared instructions.

Use a practical test instead of a broad promise. Ask a fresh session to identify the instruction source and summarize the one rule that matters for its next task. Then compare its answer with the actual record. Repeat on the teammate’s setup if shared access is the requirement.

When the rule must follow work across supported AI apps, record the human decision with its scope in fenbs. Give the repository a concise pointer to the shared work record rather than maintaining several independent copies of a changing decision.

Where should today’s progress and temporary facts go?

A stable instruction can remain useful for months. “The preview server is still running” may matter for one handoff. Treating those as the same kind of knowledge makes maintenance harder: a file of lasting rules gradually turns into a diary, while useful progress is buried among preferences.

Put changing task state beside the task. Include what changed, what was checked, what remains, and where the next session should begin. A precise note such as “The shorter form is implemented; message delivery has not been tested” gives a successor a safe starting point without claiming the work is finished.

When a temporary fact becomes a lasting agreement, promote it deliberately. A client choosing a simpler form for this job is a project decision. A team adopting a permanent rule about collecting fewer details is a broader decision that needs someone authorized to make it. Similar wording does not imply the same scope.

A useful record also preserves uncertainty. Mark an assumption as an assumption, identify an outstanding question, and say who needs to answer it. That saves the next assistant from treating a confident summary as approval. Our Claude Code memory overview provides more background on saved coding context.

How can you use both without creating conflicting copies?

Choose one current home for each statement. Put coding conventions in reviewed project instructions. Keep personal preferences in the appropriate personal setting. Keep the project’s current tasks and agreed choices in the work record. Link between those places when needed instead of copying long passages everywhere.

1. Classify the statement: preference, instruction, decision, source reference, or current progress.
2. Name its scope: this session, this project, your own work, or a wider team.
3. Choose who reviews changes and where the current answer will live.
4. Remove or correct superseded copies when the answer changes, then test a fresh session against the current record.

For example, keep “use the existing button component” in project instructions and the client’s approved form choice with the project decision. If an older saved note contradicts either, correct it. The goal is not to fill every available memory feature; it is to give the next session a clear answer it can verify.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add one active project.
2. Add its current tasks and write the last verified state. Include the next check and anything waiting on a person.
3. Record the decisions people have already made. Mark continuing instructions as rules and give them the correct project scope.
4. Connect your supported assistant from Integrations. MCP, a standard way for AI apps to use outside tools, provides access through browser sign-in.
5. Ask the assistant to read project context before starting and save progress before it stops. Keep repository-specific coding instructions in the repository.

fenbs is not the right fit if you only need one local coding convention or a personal response preference. It does not automatically import Claude memories or repair instruction files. It fits the work that another person or assistant needs to continue from an explicit shared record.

Start with the unfinished task you would otherwise explain again tomorrow. Keep its result separate from the rules for doing it, then test the next session’s understanding. The AI memory topic covers the broader choices when you need more than one kind of saved context.