Answers
How do I share the same CLAUDE.md rules across many repositories?
Claude Code gives you several ways, and each stops somewhere. The documentation I read says it loads CLAUDE.md from the working directory and every directory above it, so a file in a parent folder reaches every repository cloned below it on that machine. A CLAUDE.md can import another file with @path, and symlinks in .claude/rules/ can point to a shared folder, but an import or link that resolves outside the working directory asks for approval once per project. Directories added with --add-dir do not load their CLAUDE.md unless an environment variable is set. The user-level file applies to all your projects but only for you, and a managed policy file reaches every user on a machine only if IT distributes it. Each of those needs the same files in the same places on every person's disk, and a teammate on another tool reads none of them. When the point is that one rule applies to many repositories and to every tool, record it once on a project in Arroway and let each repository point to that project. The install page is the first step.
Last updated October 15, 2026
How the project file travels in one repository
In one repository the project CLAUDE.md is committed, a teammate gets it when they pull, and Claude Code loads it at the start of a session. The documentation recommends keeping each file under about 200 lines, and it says Claude treats the content as context, not as enforced configuration. A rule that holds for the whole team goes to Arroway, where someone sees it and approves it.
What happens with N repositories, and where each way stops
Copying the rule into every repository is the first move, and each copy drifts: the day the rule changes, someone updates four of the six. A file in a parent folder is read by every repository below it, which works only if everyone clones into the same layout and starts Claude Code from inside it. An @path import or a symlink into a shared folder keeps one source, but the documentation says a path outside the working directory triggers an approval dialog the first time, and the folder has to exist at the same path for every person. Adding a directory with --add-dir does not load its CLAUDE.md unless CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD is set. The file in your home directory is only yours, and the managed file is for an organization that can push files to its machines. In every case the rule lives in a file on a disk, and nothing in the file says who approved the rule or when it stops applying.
When to use Arroway
Use Arroway when the rule belongs to the work, not to a repository: the same rule for the API, the web app and the infrastructure code, in whichever tool someone opens them. The rule is recorded once on the project and a person approves it. Each repository only needs the short block that the install adds, which tells the agent which project to read before acting and to record what was decided when it finishes. When the rule changes, the new one names the rule it replaces, so the six repositories do not hold six versions. Claude Code, Codex, Cursor and anything else that connects over MCP read the same rule. The first step is the install page.
What it looks like in practice
A small studio keeps its work in six repositories: the website, the API, the mobile app, the infrastructure, the documentation and a scripts folder. The studio's rule is that no new dependency is added without a line in the pull request saying why. In March the rule is copied into the six CLAUDE.md files. In June the partners change it: small utility packages no longer need the line. One of them edits the API and the website files. The other four keep the old rule, and an assistant working on the scripts folder refuses to add a package it had no reason to refuse. With the rule recorded once on the project, the June change is one new rule that names the March one, with the partner's approval. The six repositories do not change, and a session in any of them reads the current rule when it opens. The studio and the rule are illustrative; nothing here was measured on a real team.
Questions people ask about this
- Is a symlink to a shared rules folder enough?
- It keeps one source on your machine and in the machines of people who create the same link. Per the documentation, a link that points outside the working directory asks for approval once per project, and a teammate who uses another tool does not read it. It also does not record who approved a rule or when it ends.
- Should every repository keep its own copy of the team's rules?
- No. Each repository needs only the short block the install adds, which tells the agent which project to read before acting. What the team has decided is recorded once on the project, where someone sees and approves it, so no repository holds a stale copy.
- How do I try Arroway?
- Install it in the tool you already use — the install page has one route for Claude, ChatGPT, Codex, Cursor or any MCP tool — and sign in when the tool asks. From then on, sessions open by reading the project and close by recording what was decided.
Where this is verifiable
The memory page of the Claude Code documentation (code.claude.com/docs/en/memory), read on 15 October 2026 — Claude Code is described only as that page describes it on that date, and its features can change in any release. Product documentation on this site (How it works, Install), the answers on keeping three instruction files in sync and on alternatives to CLAUDE.md for a team, and the sanction, supersession and expiry-condition rules in the sanctioned product spec. Everything described here about Arroway is behaviour the tools apply today, not roadmap. The studio in the example is illustrative.
https://www.arroway.app/en/answers/sharing-claude-md-rules-across-many-repos