Does Claude Desktop Read CLAUDE.md?
Claude Code sessions in the desktop app use project instruction files. Ordinary Claude chats use their own instructions and supplied context. Check the surface before changing your file.
Updated 5 min read
Claude Code sessions in the desktop app use CLAUDE.md project instructions, but you should not assume an ordinary Claude Desktop chat automatically reads a file from your repository. “Desktop” identifies the app; the kind of session determines how instructions and project files become available.
Check whether you are in Chat or Code before trying to repair an ignored rule. fenbs can keep the approved rules and current work available through supported assistant connections, so each session has an explicit shared context to read rather than relying on the app name.
Which desktop session are you actually using?
Start with the task you opened and the controls visible around it. Are you talking in an ordinary chat, working inside a chat Project, or running a Code session against a repository? Those can involve different sources of context even though they appear in the same desktop application.
| Session | Where to start | What to avoid assuming |
|---|---|---|
| Ordinary Chat | The instructions and files explicitly supplied through Chat. | A local repository is available simply because it is on your computer. |
| Chat inside a Project | Project instructions and the knowledge added to that Project. | A local CLAUDE.md is connected to the Project by its filename. |
| Claude Code in Desktop | The repository and the documented Code instruction configuration. | The selected folder is the same folder used in your terminal session. |
Anthropic’s desktop Code documentation (opens in a new tab) says Desktop and the command-line version share project memory through CLAUDE.md. That statement concerns Claude Code. Our desktop app guide gives the broader app overview if you are still deciding which surface to use.
Where should instructions go for an ordinary chat?
For one request, supply the important instructions with the request. If you attach a document, explain what role it plays: background material, an approved style guide, or instructions for the task. This gives the assistant a clearer starting point than a filename whose intended meaning it has to infer.
For recurring work inside a Claude Project, use its project instruction controls and add relevant material through project knowledge. Anthropic’s Project setup guide (opens in a new tab) describes these as separate setup actions. A document’s presence in a repository is not evidence that you have performed either action.
You can reuse the ideas from a repository instruction file, but adapt them to the actual task. A writing chat needs the approved terminology and review criteria. It probably does not need a command for compiling a backend service. Keep the instructions relevant to what this session can do.
When the same rules guide several apps, keep their human-approved source in fenbs Decisions and rules. Read that source at the start instead of treating several pasted copies as equally current.
What should you check in a Code session?
Confirm the repository folder first. A correct instruction file in the wrong checkout does not help the session you opened. Read the file in the active project and check that it contains the version of the rule you expect, especially when you have multiple copies of the repository.
Then use the instruction and context inspection supported by your Code surface. Anthropic’s memory documentation (opens in a new tab) explains the file mechanisms and the /memory interface. Verify the relevant source and ask the assistant to summarize the specific rule before requesting changes.
Make the request concrete: identify the files the task will touch, the applicable work constraints, and the verification required. Compare that summary with the repository. An assistant saying it understands the project is weaker evidence than it naming the exact rule and correct command.
For the general file mechanism, see the CLAUDE.md guide. For the differences between coding interfaces, use Desktop, CLI, and VS Code compared; those interface choices are separate from the Chat-versus-Code distinction here.
How can you test whether the intended rule reached the session?
Use a harmless planning task before allowing edits. Choose a real project constraint that is easy to recognize, such as keeping generated output unchanged. Ask which steps the assistant would take and which source supplies that restriction. You want an observable result, not a promise of perfect compliance.
- Identify the active session type and project folder, when applicable.
- Put the instruction in that surface’s supported location or explicitly supply the document.
- Start a fresh task and ask for a plan that applies the instruction.
- Check the source, rule, and proposed actions against the actual project.
- Proceed with a small change, then inspect whether the result followed the plan.
Suppose a studio uses Chat to draft release notes and Code to fix an export bug. The release-note chat should receive the approved feature names and claims. The Code session needs repository constraints and test steps. Both benefit from the same decision about what is approved for release, but they do not need identical instruction text.
If the source is missing, repair how context reaches the session. If the source is present but contradictory, resolve the conflict. If the rule is clear and the result still violates it, review the task and application controls. Adding more copies of the rule can hide the underlying issue.
What should stay shared when you move between Chat and Code?
Share the facts that determine the next action: approved decisions, project terminology, current tasks, what was tested, and what still needs review. Keep each session’s local work instructions suited to its surface. That division lets a conversation about wording and a coding task rely on the same project truth.
Before switching, write down the current state in a form the next session can read. “Export code changed; sample export still needs a person to open it” is useful. “Done” hides the unperformed check. Include who must make any pending decision so a later assistant does not choose for them.
Share the rule before moving between sessions
Save recurring instructions in fenbs Skills and prompts and approved rules in Decisions and rules. Ask a connected assistant to read the project context before planning and save progress before it stops. Chat and Code can then work from the same approved facts without requiring identical local instruction files.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account, then add a project with a short description of the work.
- Record the rules people have agreed and leave unresolved decisions open. Save reusable instruction text in Skills and prompts.
- Follow the integration guide for the Claude connection you use. MCP, the standard for connecting an assistant to an outside tool, requires an actual supported connection.
- Ask the assistant to read the project context and explain its next step before working.
- Save progress and outstanding checks in Where we left off before moving to another session.
fenbs does not make an ordinary desktop chat read local files automatically. If you only need a one-off answer with an attached document, that may be sufficient. Use a shared record when rules and unfinished work must remain usable across sessions; the AI prompts hub has related setup guides.