Persistent codebase memory for Claude Code

Why does Claude Code forget your codebase between sessions?

Claude Code reads files per session and compresses context as the window fills up. Without a persistent artifact, every new session has to rediscover structure, which costs tokens and can miss relationships that span many files.

• Context windows fill quickly on large repositories.
• Fresh sessions re-read files that were already understood yesterday.
• Flat file reading hides how modules connect to each other.

How do you give Claude Code persistent codebase memory?

Build a graph with Graphify, then keep the artifacts where Claude Code can read them. Reference GRAPH_REPORT.md from CLAUDE.md so each session starts with structure, and keep graph.json available for tools and deeper queries. Local users can also run the open-source Graphify skill directly inside their assistant workflow.

• Add the downloaded graph artifacts to the project workspace.
• Point CLAUDE.md at GRAPH_REPORT.md for an automatic structural briefing.
• Keep graph.json alongside for scripted or tool-based queries.

When should you refresh Claude Code project memory?

Refresh the graph after refactors, migrations, and boundary changes. A stale map is worse than no map because it points sessions at structure that no longer exists.

• Rebuild after large refactors or dependency changes.
• Refresh before onboarding onto an unfamiliar subsystem.
• Keep a dated report so reviewers can compare structure over time.

Should you use CLAUDE.md, a retrieval plugin, or graph artifacts?

CLAUDE.md is a hand-written brief for conventions, commands, and preferences, and it drifts as the project evolves. Retrieval plugins fetch relevant files at question time, but every answer still pays the cost of reading code. Graph artifacts sit between the two: structure compiled once, refreshed deliberately, and available to every session without re-reading the repository.

• CLAUDE.md stays best for rules, commands, and team conventions.
• Retrieval plugins locate code live but re-derive relationships per question.
• Graph artifacts keep structure fixed across sessions at a one-time build cost.

What does the workflow look like from ZIP to a Claude Code session?

The hosted flow is short by design. Package the project as a ZIP and upload it; the build runs in the cloud with no local Python or parser setup. Download graph.html, graph.json, and GRAPH_REPORT.md into the project, then reference the report from CLAUDE.md. Each later session opens with a structural briefing instead of a blank start. Teams that prefer a fully local setup can run the open-source Graphify skill inside the assistant instead.

• Upload a project ZIP; extraction and clustering run in the cloud.
• Keep the three artifacts in a docs folder inside the repository.
• Point CLAUDE.md at GRAPH_REPORT.md so sessions open with structure.
• Optionally switch to the open-source skill for fully local runs.

How do you keep Claude Code context usage under control?

A context limit rewards summaries over raw files. A graph report compresses structural facts (the central files, the subsystem boundaries, the risky edges) into a document a session can hold cheaply. Use it to decide which two or three files are worth reading in full, so the window is spent on the code you can change instead of rediscovering the rest.

• Open sessions from the report instead of broad file reads.
• Ask structural questions first: what depends on this, what does it touch?
• Read full files where the map shows risk or active change.

What changes when the whole team shares the memory?

One person's notes become the team's shared reference the moment the artifacts live in the repository. Reviews start from the same map, new members read the same report, and AI assistants answer from the same structure. The habit that makes it work is small: when the graph is refreshed, everyone reads the delta together instead of rebuilding private mental models.

• Keep the artifacts in the repository so everyone reads one source.
• Start reviews from the map, then look at the diff.
• Refresh together after big changes and share what moved.