Should you commit CLAUDE.md and the .claude folder?

Which files in .claude should I commit?

Should I commit the .claude folder?

Mostly, yes. The docs put it plainly: commit most files in .claude/ so the team shares them. The one file that should never be tracked is settings.local.json, and Claude Code handles it for you: the first time it writes that file in a repo that does not already ignore it, it adds **/.claude/settings.local.json to your global git excludes. That protects you, not your teammates. If you want the rule in the repo, add the same line to the project .gitignore.

Tracking the local file has a side effect worth knowing. While it is untracked, its allow rules apply without the workspace trust step. Once git tracks it, the trust step applies to it as it does to the committed settings.json.

What is CLAUDE.local.md for?

Your sandbox URLs, your preferred test data, anything true for you and not for the team. Claude Code loads it after the CLAUDE.md at the same level, so it is the last thing Claude reads there. Two traps:

• It only exists in the worktree where you created it. For notes that follow you across worktrees, import a file from your home directory instead.
• It counts as a CLAUDE.md for the AGENTS.md check. In a repo that relies on AGENTS.md, creating one stops Claude reading AGENTS.md for you under the default mode.

Is it safe to commit .claude/settings.json?

It is safe to commit and worth reviewing like code, because it is code. The settings docs recommend committing it so everyone gets the same permissions, hooks and plugins. A hook in that file runs shell commands on every teammate's machine, which is why Claude Code asks each person to trust the workspace before project hooks and allow rules take effect. Keep secrets out of its env block; it is in git.

The same caution applies to CLAUDE.md imports. The first time Claude Code sees an @path import that resolves outside the working directory, it asks for approval, because a file someone else committed chose what gets loaded.

Should CLAUDE.md be in .gitignore?

The project file, no. Ignoring it means every engineer writes their own, and the agent on each laptop works from a different brief. If something in it is personal, that line belongs in CLAUDE.local.md; if it is true for you in every repo, it belongs in ~/.claude/CLAUDE.md. The one case for keeping a project file out of a public repo is content you would not publish: internal hostnames, customer names, incident details. Strip those rather than ignore the file.

Can I commit Claude Code's auto memory?

Not in any supported way. Auto memory is written to ~/.claude/projects/<project>/memory/, one directory per repository shared across its worktrees, and the docs say plainly that it is not shared across machines or cloud environments. The autoMemoryDirectory setting moves it, but only to an absolute path or one under ~/. When Claude saves something the whole team should know, the route today is by hand: open MEMORY.md with /memory, copy the line into CLAUDE.md, and open a pull request.

How do I share CLAUDE.md with my team?

Commit it, and review changes to it in pull requests like any other file. For rules that must reach every repo in the company, an admin can deploy a managed CLAUDE.md to a fixed system path (/Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux). Managed files cannot be excluded by individual settings.

What git does not solve

Git answers where the file lives and who changed which line. Three questions stay open.

• Who reviews a rule? A pull request review checks the diff. It does not check whether the line is still true, or whether it contradicts a line someone else added in another directory. The docs warn that when two rules conflict, Claude may pick one arbitrarily.
• Where does the rule come from? The decision that webhook handlers acknowledge and enqueue was made in #eng-payments and argued again in a review thread. It reaches the file only when someone remembers to copy it.
• What does each agent actually get? Claude Code's auto memory is machine-local and not synced. What one engineer's agent learned on Tuesday is not in anyone's committed file on Wednesday, and a teammate on Codex never sees it.

Harbor is built for those three. It reads the places the team already decides (Slack channels you opt in, merged pull requests and their review threads, docs) and turns them into facts. You set the gate: under the default Hybrid mode routine conventions are added automatically, and anything that contradicts an existing fact is always held for a person. harbor init wires the same approved facts into Claude Code, Codex and Cursor, and what a session learns is written back for review, not straight into anyone's prompt. The quickstart is the place to start.

Related: how each agent's memory is scoped and one memory for Claude Code, Cursor and Codex.