How to share CLAUDE.md across projects or a team

Pick the method by who needs the instructions

Share with your team through the repo

Commit the project file and put in it what any teammate needs: build and test commands, conventions, architecture decisions. Keep personal lines out. Your sandbox URL or test account goes in ./CLAUDE.local.md, added to .gitignore.

/init generates a starting file, and suggests improvements if one already exists. To split a big project file by topic, add files to .claude/rules/ and commit those too. A paths field limits a rule to matching files.

In a monorepo where another team's CLAUDE.md gets picked up, each developer can skip it from .claude/settings.local.json:

{
  "claudeMdExcludes": ["**/monorepo/other-team/CLAUDE.md"]
}

Share across your own projects

Instructions in ~/.claude/CLAUDE.md load in every project, with no extra setup. Use ~/.claude/rules/ for several topic files, such as preferences.md and workflows.md. Both stack with each project's own files, and neither overrides the other. If a user rule and a project rule conflict, Claude may follow either, so keep them consistent.

This is also where people get stuck: project facts in the user file leak into every repo, and personal habits in the project file get committed for everyone. Rulebook, the Mac app we are building, shows the user, project and local levels side by side and moves a rule between files with a drag.

Reuse one file across several repos

With an import

Add a line to each repo's CLAUDE.md pointing at the shared file:

# Company standards
- @~/company-standards/claude.md

A path outside your working directory counts as external. The first time Claude Code meets one in a project, a dialog lists the files. Decline and the imports stay disabled, and the dialog doesn't return. Details are in how to import files into CLAUDE.md.

A path in your home folder only works for people who have the file there. For a team, commit the shared file into each repo or use a managed CLAUDE.md.

With symlinks in .claude/rules/

ln -s ~/shared-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.md

Links that point outside your working directory wait for the same one-time approval. After you approve, only linked rules without a paths field load. Keep path-scoped rules as real files in the project, or in ~/.claude/rules/, which needs no approval. Links to a network path such as /Network don't load at all.

With --add-dir

--add-dir doesn't load a folder's CLAUDE.md unless you set an environment variable:

CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../shared-config

That loads CLAUDE.md, .claude/CLAUDE.md, .claude/rules/*.md and CLAUDE.local.md from the added folder. To keep it on, add the variable to the env block in ~/.claude/settings.json.

Share across git worktrees

A gitignored CLAUDE.local.md exists only in the worktree where you created it. To carry personal instructions across worktrees of one repo, import a file from your home folder:

# Individual preferences
- @~/.claude/my-project-instructions.md

Share across a company

On a Mac, a managed file lives at /Library/Application Support/ClaudeCode/CLAUDE.md. Distribute it with MDM, Group Policy, Ansible or similar. It applies to all users on the machine in any repository, and claudeMdExcludes can't skip it. You can also put the text in the claudeMd key of managed-settings.json.

Managed instructions are still guidance. Use managed settings for limits that must hold, such as permissions.deny, and see where Claude Code hooks go for steps that must run.

Confirm it worked

Run /context all in a session and read the Memory files list. For the order files load in, see where Claude Code looks for CLAUDE.md.