How to Give Claude Code Full Context of Your Codebase

Claude Code is powerful, and it explores a codebase well: grep, glob and read are precise, and it uses them without being asked. What it does not have is any memory of the last session. On a codebase you work on every day, that shows up fast: it loses track of the architecture it worked out yesterday, and repeats questions you answered two sessions ago.

There are four approaches to giving Claude Code the context it lacks — from the basic to the comprehensive. This article covers all four, including the one we sell, and says where each one stops.

Approach 1: Point it at the files (the default)

The simplest approach is to name the files that matter in your prompt, or paste the relevant part. Claude Code reads them with its own Read tool and finds the rest with grep.

• Works for: Small projects, quick one-off tasks, files you already know by name
• Breaks when: The same explanation is needed tomorrow; the architecture is not visible from any single file
• What survives the session: Nothing

Approach 2: Write a CLAUDE.md file

CLAUDE.md is Claude Code's built-in project memory mechanism. When present in your project directory, it's automatically read at the start of every session. A well-written CLAUDE.md describes your project's architecture, conventions and key files — giving the AI a map before it starts navigating.

# MyProject — FastAPI + React
# Auth: JWT (backend/auth/), DB: PostgreSQL via SQLAlchemy
# Entry points: backend/app.py, frontend/src/App.tsx

# CONVENTIONS
# Always async/await, never sync DB calls
# Error format: {"error": "message"}

# NEVER
# Drop tables directly — always use Alembic migrations

• Works for: Establishing conventions, preventing common mistakes, naming entry points
• Breaks when: The codebase evolves and the file gets stale; what the agent learned in a session is not in it, because nobody wrote it down
• What survives the session: What you wrote by hand, as of the day you wrote it

CLAUDE.md is worth writing and keeping short. For best practices, see our complete CLAUDE.md guide.

Approach 3: Have the agent write a handoff

Before a session ends, ask Claude Code to write down what it did, what is open, the traps it found and the next step — in a file in the repo, or in its own auto-memory. The next session, tell it to read that first. This is the biggest single improvement most people never make: the knowledge was there, it only needed writing down.

• Works for: Any project, from the first day; costs nothing
• Breaks when: Someone forgets — the agent to write it, you to ask for it back; the file grows and nobody prunes it; two people or two agents write over each other
• What survives the session: Whatever the agent remembered to write, in prose

Approach 4: A memory the agent writes, and hooks that read it back

The most complete approach removes the "someone forgets" from approach 3. This is what Codelux AI provides, through a Claude Code plugin and a local MCP server:

• Memory written by the agent: at the end of a task it calls memory_set with a free JSON — summary, next step, open points, traps, decisions, facts anchored to file:line, todos, a map of the code it touched. Saved whole, returned whole.
• Hooks, so nothing depends on remembering: a SessionStart hook puts the newest memory in context with what changed in its files since; a UserPromptSubmit hook adds a relevant codemap, fact or decision when your prompt touches one; a Stop hook reminds the model to save if it has not.
• An AGENTS.md / CLAUDE.md block: status, next step, traps and recent decisions, rewritten by Codelux AI on every save — so even an agent without hooks reads it.
• Notes and a timeline: todos and forms between you and the agent; every memory, note, edit, commit and lock recorded with who and why.
• A file semaphore: a hook takes a lock around each of Claude Code's own edits, so several agents on the same checkout do not write over each other.

• Works for: Daily AI-assisted development; several agents on one checkout; teams sharing a project
• Setup: Download, run codelux start, add the project, claude plugin install codelux@codelux
• What survives the session: The memory, the notes, the timeline — on your machine, in the project's own databases
• What it leaves to Claude Code: Searching, reading and editing the code: Claude Code's own grep and Edit stay in charge; the plugin only takes a lock around each edit

What this looks like in practice

With the Codelux AI plugin, a typical Claude Code session goes like this:

1. The session starts — the hook puts yesterday's memory in context: "retry race fixed; next: webhook test; trap: Stripe test keys expire after 90 days", plus the two files that changed since.
2. You ask for the webhook test — the prompt hook adds the "payments / webhooks" codemap the agent saved last week, with its two files.
3. Claude Code edits with its own Edit tool — the hook takes the lock on the file before and releases it after; if another agent held it, Claude Code would be told who and for how long.
4. Before it stops, it calls memory_set with what it did and what comes next — or the Stop hook reminds it.

The AI works from what previous sessions recorded, and you do not spend the start of every conversation re-explaining your project. Everything it did is on the timeline, for you and for your team.

Which approach should you use?

• Tiny project, one-off task: point it at the files
• Any real project: start with CLAUDE.md, keep it under 50 lines
• Any project you come back to: have the agent write a handoff, today
• Daily development, several agents, a team: a memory the agent writes and hooks read back

← Back to the blog