Claude Memory: Help Claude Learn Your Codebase

Helping Claude learn your codebase means giving it verified facts about the structure, build commands, and key conventions—not pointing it at every file and hoping it absorbs them. A short, accurate record that an assistant can read in seconds is more useful than a large one it cannot finish before running out of context. Tools like fenbs keep shared findings and onboarding tasks outside any single chat so the next session starts from what is already known.

Claude does not retain what it reads between sessions unless you save it somewhere. Each new conversation starts from zero. The goal is to make that starting point as informative as possible with the smallest amount of text.

What belongs in a codebase memory

Start with what a new developer would need to know in their first hour. Most of that is not the code itself—it is the commands, the layout, and the rules that are not obvious from reading the files.

• Build and run commands: how to install dependencies, start the dev server, run tests, and build for production.
• The folder layout: what lives where and why. One sentence per major folder is enough.
• Conventions: naming rules, import style, where to add a new component or route.
• Known constraints: files that must not be edited, commands that are destructive, steps that need a person's approval.
• Key references: the file that defines the data model, the file that controls routing, the config that switches environments.

Leave out the actual source code. Claude can read files when it needs them. What it cannot do is remember, without a record, which file holds the thing it already found. Save the pointer, not the content.

Architecture notes versus raw source

An architecture note says "the data model lives in packages/types/src/domain.ts" and "the service layer in packages/api/src/service.ts is the only place permissions are enforced." That is useful in one sentence. Pasting the contents of those files into memory is not useful—it grows stale the moment the file changes and fills the context window before Claude can read anything else.

Notes should describe decisions, not duplicate code. "We use single quotes throughout; the linter enforces this" is a decision note. "We tried double quotes in 2025 and changed back because of X" is also worth recording—it explains the rule and stops the same conversation from happening again.

See claude-project-memory for how Claude Code Project knowledge files work and where they are stored.

Verified findings versus assumptions

Mark each note as verified or provisional. "All API calls go through fetchWithAuth (confirmed October 2026)" is a fact someone checked. "The search endpoint may also accept a POST—unconfirmed" is a provisional note that a future session should verify before relying on it.

Claude may read a function and infer something about how it works. That inference can be useful and can also be wrong. Put inferences in the provisional column and check them before they become rules. One wrong rule in the codebase notes will mislead every session that reads it.

Claude Code Projects shared memory, added September 17, 2026, lets a team share the same memory files inside a Claude Code Project. That helps with the verified/provisional distinction: teammates can mark a note as confirmed, or flag it as outdated, and all sessions see the update.

Source references without copying code

Instead of pasting a function, record where it lives and what it does. "The permission check is allows() in packages/ui/src/permissions.ts:14—it reads the user's role from context and returns a boolean" tells Claude where to look and what to expect without putting the source in the notes.

Use file-and-line references for anything Claude is likely to need in a session. When it reads the file, it can confirm the note is still accurate. When the note and the file disagree, it knows something changed and can flag it.

Key commands and onboarding tasks

Keep your CLAUDE.md or AGENTS.md short—a page or two—and save the long onboarding notes somewhere else. CLAUDE.md is injected into the context window at session start. A very long file pushes out the space Claude needs to read recent work and new instructions.

Put the most-used commands in CLAUDE.md so they are always available. Put the less-frequent setup notes in a separate file and point to it. "See .claude/codebase-notes.md for the full architecture map" is enough—Claude will read it when it needs to.

Onboarding tasks belong in your task tracker. "Confirm how authentication tokens are refreshed" is a task, not a note. When someone completes it, they record the finding as a note and close the task.

How to do this with fenbs

Connect Claude Code to fenbs over MCP. At the start of each session, Claude Code reads the AI context: Rules first, then Where we left off, then context notes. Notes you add about the codebase appear there automatically.

1. Create a free account and add your project in fenbs. Give it a short description of the codebase—what it does and what technology it uses.
2. Connect Claude Code from Integrations. Follow the MCP guide, sign in in the browser, and approve read and write access.
3. Add the first batch of context notes through fenbs: build commands, folder layout, key files and what they own. Mark each as verified or provisional.
4. Ask Claude Code to read the project context at the start of each session. After it reads a file and confirms a provisional note, ask it to update the note in fenbs with the confirmation date.
5. Add onboarding tasks for findings that are not yet confirmed. When a session completes one, record the result as a context note and move the task to done.

fenbs does not import your Claude chat history or read your repository automatically. You or Claude Code add the notes by hand during a session, based on what you discover.