[DOC] CLAUDE.md discovery - documentation is inconsistent

Status Fixed / completed
Maintainer reply None cached
Activity 11 comments · opened Apr 6, 2025 · closed Apr 8, 2025

Description

There is conflicting information on the docs website about how/where Claude Code can find CLAUDE.md files in the directory tree. (This is an issue that has come up in a few Issues lately.)

Here it says:

How Claude looks up memories

Claude Code reads memories recursively: starting in the cwd, Claude Code recurses up to / and reads any CLAUDE.md or CLAUDE.local.md files it finds. This is especially convenient when working in large repositories where you run Claude Code in foo/bar/, and have memories in both foo/CLAUDE.md and foo/bar/CLAUDE.md.

TL/DR: Claude recurses up the directory tree starting from where you open your session

(No mention is made of a boundary point.)

Here

You can add CLAUDE.md files to any of:

The folder you run Claude in: Automatically added to conversations you start in that folder
Child directories: Claude pulls these in on demand
~/.claude/CLAUDE.md: User-specific preferences that you don’t want to check into source control

So one source says Claude traverses up (the entire directory tree?? I kind of doubt it(?)) and the other source says it can look down and also at $HOME.

  • What's the fact of the matter?
  • What happens with conflicting information? Is there a precedence order?
  • Does Claude really traverse the directory tree all the way from CWD to $HOME?
  • When are memories "loaded" up? It says some are on launch, some are "on demand"?
  • Does Claude notice manual changes to CLAUDE.md files(?). If so, is it only in a new session?
  • What's the difference between CLAUDE.local.md and .claude/CLAUDE.md? Docs suggest they're both for personal, non-checked-in memories. I figured .claude/ was for storing docs and commands and stuff, but then I don't see the distinction between these two alternative CLAUDE files. (EDIT: Come to think of it, if .claude/commands holds slash-commands that might be team-wide, e.g. part of CI/CD or something, then it's not right to think of claude/ as a User-preference thing.)
  • I think there's an implicit assumption that a Claude Code workspace is supposed to correspond to a git repo. That's reasonable, but wasn't obvious to me, and isn't documented. And what about monorepos, etc.? Should I put a CLAUDE.md file in every sub-module, for example?
  • Can Claude access "cousin" directories? If i'm in foo/bar for the bar module in the foo repo, will it read foo/baz/CLAUDE.md if I ask it about foo/baz? (Is it even allowed to look there?)
  • Does claude -p also respect CLAUDE.md files or no? Does it follow the same rules?

Too much guesswork going on here, IMO! I hope as the team moves out of beta, these rules will become more documented and codified. I love this tool, I hope it continues to improve, and I'd love more transparency/observability about these aspects, otherwise I don't see how it can be incorporated into a production workflow, CI/CD, etc.

View original on GitHub ↗

11 Comments

hesreallyhim · 1 year ago

Linked to:
#707
#705

ChristopherA · 1 year ago

I regularly put multiple repositories in a directory with a CLAUDE.md that has a simple rule to list the repositories in the current directory, ask which one to load, and then load a context there. That context can be named anything.

See also https://github.com/ChristopherA/Claude-Code-CLI-Toolkit which has a different context for every branch of a repo.

hesreallyhim · 1 year ago

@ChristopherA Nice! I'll definitely check it out. Still, it's a custom toolkit, doesn't answer/resolve the questions/issues about Claude Code itself

ChristopherA · 1 year ago

I guess one of my concerns is having the predefined CLAUDE.md, et al, do too much or lock you into not being able to customize for specific needs (like I do with a context per branch, but maybe you need some other organization).

Instead I’d like have more use of things that Claude Code can do better than I can. For instance, I’d like to see the /compact output be available (see https://github.com/anthropics/claude-code/issues/667 ) for my use.

So back to your root issue, which is that these special files are not well documented, I’d almost argue we shouldn’t predetermine them. For instance, currently # text gets appended to CLAUDE.md, but I don’t want it there, I want it applied to my current context file. If Claude Code doesn’t know where that is on first use, it should ask me, while offering a useful default, but not requiring it.

ghost · 1 year ago

Thank you for the feedback! Great questions - will update our docs to make it more clear.

https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview#determine-memory-type is the best resource for CLAUDE.md locations

What happens with conflicting information? Is there a precedence order?

All CLAUDE.md's described here are included when you first launch Claude. When setting up your CLAUDE.md's you need to take care to not include conflicting instructions.

Does Claude really traverse the directory tree all the way from CWD to $HOME?

Claude traverses from CWD to / (i.e. to root, not $HOME)

When are memories "loaded" up? It says some are on launch, some are "on demand"?

Claude can read any file under CWD (including nested CLAUDE.md's) on demand, but only the CLAUDE.md's outlined here are loaded automatically on launch.

Does Claude notice manual changes to CLAUDE.md files(?). If so, is it only in a new session?

Not currently - new sessions will pick up changes on launch.

What's the difference between CLAUDE.local.md and .claude/CLAUDE.md? Docs suggest they're both for personal, non-checked-in memories.

$cwd/CLAUDE.local.md is for project-specific instructions (similar to $cwd/CLAUDE.md, but not checked in so you can use it for project-specific instructions that are only relevant to you), ~/.claude/CLAUDE.md applies to all projects.

what about monorepos, etc.? Should I put a CLAUDE.md file in every sub-module, for example?

Yes, that is a convenient way to have instructions for sub-modules and for the entire repository at the same time. If you have repo/CLAUDE.md and repo/module/CLAUDE.md, then when you launch claude from repo/module it will get both instruction files loaded.

Can Claude access "cousin" directories? If i'm in foo/bar for the bar module in the foo repo, will it read foo/baz/CLAUDE.md if I ask it about foo/baz? (Is it even allowed to look there?)

Claude can read cousin directories if you specifically prompt it to, but it is not automatic like reading CLAUDE.md's on launch.

Does claude -p also respect CLAUDE.md files or no?

yes, claude -p works the same way

hesreallyhim · 1 year ago

@levpopov thanks for the clarifications

max-sixty · 1 year ago
Claude can read any file under CWD (including nested CLAUDE.md's) on demand, but only the CLAUDE.md's outlined here are loaded automatically on launch.

fwiw this seems to conflict with

Claude traverses from CWD to / (i.e. to root, not $HOME)

...and the subsequent section in the docs, unless I'm missing something?

it seems that a parent CLAUDE.md _is_ included in the context window. from claude — we get the file in our current worktree and the one in a parent dir

⏺ Yes, the full contents of all three CLAUDE.md files are in my context window:

  1. User's private global instructions (/Users/maximilian/.claude/CLAUDE.md)
  2. Project instructions from main repo (/Users/maximilian/workspace/xarray/CLAUDE.md)
  3. Project instructions from current worktree (/Users/maximilian/workspace/xarray/.worktrees/traceback/CLAUDE.md)
isCopyman · 1 year ago

Can the discovery of slash commands also follow a similar pattern?

alexx-ftw · 1 year ago

Does `claude -c` re-load CLAUDE.md ?

hesreallyhim · 1 year ago

@alexx-ftw it's supposed to be i believe, yes - you can try asking Claude or also look at the logfile - when you run -c it creates a new jsonl file but it copies over the old convo as well - so you could maybe tell something from that, but don't rush to conclusion. Probably there's a few factors in play, like whether CLAUDE.md changed, and how long the conversation has been.

github-actions[bot] · 1 year ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.