How to Stop Coding Agents Re-Reading the Same Files
Short answer: a coding agent re-reads files because each new session starts without what the last one learned. To stop it, give the agent a short map it loads at startup (CLAUDE.md or AGENTS.md), name the files you mean, resume a session instead of starting over when the work continues, keep exploration in a subagent, give it code navigation instead of grep, and keep what it learned about the code somewhere it can find next time.
The rest of this post is why each of those works, what each costs, and where each stops. Product details are as of October 2026.
Why your agent reads the same files every session
Three things combine.
A new session is a new context. Prompt caching makes re-sending a conversation cheaper within a session, but Claude Code's cache is scoped to one machine and directory, expires after minutes to an hour, and has no per-file caching. Tomorrow's session does not inherit today's file reads.
Built-in memory is deliberately small. Claude Code's auto memory loads only the first 200 lines or 25KB of its MEMORY.md at startup, and it skips architecture, file paths and debugging fixes by design. Codex memories are off by default and stay on your machine. Neither is meant to hold a map of your codebase.
Vague requests trigger broad scanning. Anthropic's own cost guidance says it plainly: when the agent does not know where to look, it greps, then reads every candidate file.
1. Give it a map it loads at startup
A short CLAUDE.md (Claude Code) or AGENTS.md (Codex, Cursor and most other agents) that says where things live: which directory owns what, how to build and test, which files are generated. The agent reads it before its first answer, so it starts knowing where to look.
Keep it short. Claude's docs suggest staying under 200 lines per CLAUDE.md, and Codex stops reading its AGENTS.md chain at 32 KiB by default. Put detail lower down: a CLAUDE.md inside a subdirectory loads only when the agent works there, and a "codebase overview" skill loads only when it is needed.
Where it stops: it is written by hand, and it goes stale the week someone moves a module. And a map of where files are is not the same as what the team learned inside them.
2. Name the files you mean
"Fix the retry bug in internal/queue/client.go, in publishWithRetry" costs a fraction of "fix the retry bug". If you know the file and the function, say so. If you don't, ask the agent to plan first and confirm the files before it starts reading.
3. Resume instead of starting over
If you are continuing yesterday's work, resume yesterday's session: claude --continue or claude --resume in Claude Code, codex resume --last in Codex. The full history comes back, tool results included, so the files it read are already in context.
Where it stops: resuming a long session that has gone idle reprocesses its history once without the cache, and it only works for the same thread on the same machine. A teammate, or you in a different agent, starts from zero.
4. Keep exploration out of the main context
Claude Code's Explore subagent is read-only and keeps what it reads out of your main conversation; you get its findings, not every file it opened. It can run on a smaller, cheaper model.
Where it stops: the exploration still happens, and still costs tokens. You have moved the reading, not removed it.
5. Give it navigation instead of grep
Code intelligence turns "grep, then read five candidate files" into one lookup. Anthropic's cost guide notes that a single "go to definition" call replaces a grep followed by reading multiple files. Options include language-server plugins for Claude Code, Serena (language-server symbol tools over MCP), Aider's repo map (a ranked map of symbols, about 1,000 tokens by default) and Claude Context (semantic code search; it needs a vector database and an embedding key).
Where it stops: these find code faster. They do not tell the agent why the code is the way it is.
6. Keep what the agent learned, not just where the code is
Here is the part the other five miss. Reading client.go again is cheap. What is expensive is re-learning, from scratch, that the retry lives there because the queue drops messages under load, that a cleaner approach was tried in March and reverted, and that the fix for last month's duplicate deliveries depends on it. The agent re-reads the file, misses all of that, and proposes the cleaner approach again.
That knowledge needs a home that is tied to the files it is about, and that the next session can find without being told. Options, as of October 2026:
- Claude Code auto memory and Codex memories: built in, automatic, but on one machine and, in Claude Code's case, not meant for architecture or file paths.
- claude-mem: records each Claude Code session on your machine and brings the relevant parts back. Good for one developer.
- Recallium: keeps the decisions, root causes and fixes your agents work out, each linked to its files and commit. Before the next edit, Recallium finds what the team already settled about that code and feeds it to the agent: yours tomorrow, a teammate's in Cursor, or Codex next week.
npx -y recallium install
The installer finds Claude Code, Codex, Cursor and your other agents and connects them to the same memory. Join the waitlist for Recallium Cloud.
What doesn't work
- Pasting the whole codebase into CLAUDE.md. It loads every session, so you pay for all of it every time, and the agent still has to open files to edit them.
- Counting on the cache across days. It expires in minutes to an hour, and it never covered a new session anyway.
- One huge notes file nobody updates. It works until the second teammate. Then it is stale, conflicts on merge, and loads whole.
The short version
Start with a short map (1) and specific asks (2); they are free. Resume when you continue the same work (3). Add a subagent (4) and code navigation (5) when the codebase is large. And when the problem is not finding the code but re-learning why it is that way, give your agents memory tied to the files (6).
More on each agent's own memory: Claude Code, Codex and Cursor.