How to make a single root CLAUDE.md load across your whole organization

The mental model goes like this. Drop one CLAUDE.md at the root of your company SharePoint site. Sync the site to OneDrive. Every Claude session at the company picks the file up from there. Done. One source of truth for AI policy, firm context, and shared skills, propagating itself everywhere by virtue of the folder layout.

The mental model is rubbish, and the gap matters more than people realize.

Microsoft SharePoint inherits permissions, retention policies, and sensitivity labels from parent folders into child folders. It does not inherit files. A CLAUDE.md placed at the site root does not appear inside subfolders by virtue of the layout, and no Claude product walks SharePoint hierarchy looking for special files at session start. The Microsoft Learn permissions inheritance reference spells this out plainly. What passes from parent to child is the permission setting, not the content of the parent.

So the layout-first instinct produces a CLAUDE.md that loads precisely nowhere. Which is the opposite of what you wanted.

So how do you actually make one root file land on every Claude session in the firm, given that none of the surfaces will pick it up by walking SharePoint hierarchy?

This post walks through what does work. One canonical root file, four parallel loaders pulling from it, reaching every Claude surface in the firm. Each loader is small. Skipping any one of them leaves a surface that does not see the source of truth.

Why doesn’t one CLAUDE.md propagate?

This puts my back up about the way most firms approach CLAUDE.md. The reason every Claude session at a company benefits from one source of truth is mundane. Without it, every user re-explains Fortune Five Hundred plumbing to Claude in every session. AI policy fragments across teams, with one finance analyst getting a different idea of “approved tools” from a sales rep two doors down. Use cases stay siloed in personal folders because nobody knows what the canonical pattern is. The first time you watch three different Claude sessions at the same firm interpret the same acronym three different ways, the gap is obvious.

The goal is one root file every Claude product picks up, without each user having to think about it. Easy to say. Hmm, that needs unpacking, because “every Claude product” is at least five surfaces, and they all read CLAUDE.md a different way.

Here is the per-surface table for what actually loads, today, on each surface.

Six entries on the right side. One source of truth needed on the left. They do not match up, and there is no single Claude knob that joins them.

Even the Claude Code parent walk has a quieter trap. Subdirectory CLAUDE.md files inside the same synced repo only load when Claude actually touches files in that directory during the session. Thomas Landgraf, in a working post on Claude Code’s memory model, puts it cleanly: “Subdirectory memory files are only loaded when Claude actually accesses files in those directories.” So even within the parent-walk model, the loading order depends on which files the session interacts with, not on filesystem structure alone.

The conclusion is that any “single source of truth” plan based on putting the file in the right folder and hoping is going to leak. The folder is fine as the canonical location. It just is not the loader.

The 4-track architecture

Now stay with me on this one, because the fix is unfashionably small. Or really, four small fixes, each handling one of the loaders. One canonical CLAUDE.md in SharePoint, plus four parallel pulls from it that reach the four surfaces.

The SharePoint root stays as the editorial source. Each track is a different way of getting the same content into a place where one specific Claude surface will read it. Tracks two through four are derived from track one’s file. Edit the SharePoint copy, regenerate downstream.

Track 1: SharePoint root + OneDrive sync (Claude Code, parent-walk)

Users sync the relevant SharePoint document library via the OneDrive client on their laptop. From any subfolder under that synced root, Claude Code walks the directory tree on session start and loads every CLAUDE.md it finds, with the root-most file injected first.

Anthropic documents this directly. When Claude Code starts in a subdirectory of an OneDrive-synced repo, it will pick up Departments/CLAUDE.md automatically if the user is operating from Departments/Finance/ or any depth below that. The user does not type a path, does not choose a file, does not even know it happened.

You can prove this on any machine. Drop into a subfolder, list a few parents, see what is sitting there.

That output is from this site’s own checkout. Two CLAUDE.md files at two parent levels, both real, both loaded automatically when Claude Code starts in the post directory. The deeper one (2,859 lines, project root) gives the project-specific rules. The shallower one (812 lines, GitHub root) covers all the repos under it. Both inject into context on every session in this directory tree.

Track one is free if your team already syncs SharePoint to OneDrive. The cost is one file at the right place in the tree (so, ten minutes of work spread across a Monday afternoon, give or take).

Track 2: Managed settings, the guaranteed Claude Code loader (console or system-policy file)

Track one covers anyone who runs Claude Code from inside a synced subfolder. It does not cover the developer running Claude Code from /tmp or from a private repo outside OneDrive. For those sessions you need org config that loads no matter where the user starts. There are two ways to deliver it, and on a Team or Enterprise plan the easier one needs no device management at all.

Server-managed settings, the no-MDM path. An Owner opens the admin console at claude.ai under Admin Settings, Claude Code, Managed settings, and pastes a block of JSON. From the docs, clients “receive the updated settings on their next startup or hourly polling cycle.” No file on any laptop, no Intune package, no Jamf. It wants Claude Code 2.1.38 or later on Team, or 2.1.30 or later on Enterprise. The setting that carries your org policy is claudeMd, described in the settings reference as “CLAUDE.md-style instructions injected as organization-managed memory” that is “only honored when set in managed or policy settings.” So the parent’s policy content rides the console as a settings value, not a file you have to copy. And managed settings sit at the top of the precedence order: the docs say no other level can override them, “including command line arguments.”

This is the answer to the question every IT lead asks first, which is whether someone has to copy the file to every machine every day. No. You paste it once, edit it in the console when firm facts change, and clients pull the new version inside the hour.

System-policy file, the MDM path. The older mechanism still works and is the stronger one on unmanaged devices. Anthropic supports a managed CLAUDE.md at a fixed OS path. Verbatim from the Memory documentation: “This file cannot be excluded by individual settings.” The paths:

• macOS: /Library/Application Support/ClaudeCode/CLAUDE.md
• Windows: C:\Program Files\ClaudeCode\CLAUDE.md
• Linux and WSL: /etc/claude-code/CLAUDE.md

On most Macs the directory does not exist by default. IT creates it and drops the file in via Jamf, Kandji, Intune for Mac, or Ansible. Once present, every Claude Code session on the machine loads it, and no user setting can opt out.

Anthropic ships example MDM payloads on GitHub covering Jamf and Kandji on macOS and Intune and Group Policy on Windows. A small Win32 app or signed .pkg that copies one file is enough. Detection rule: file exists at the target path with a hash matching. Refresh: re-push when the SharePoint root changes.

Which one to reach for? On Team or Enterprise the console is less work and refreshes itself, so most firms should start there. Reach for the MDM file when you want OS-level enforcement a user with admin rights cannot quietly edit, or when you are not on a plan that offers server-managed settings. Plenty of shops run both: the console for reach, the system-policy file as the belt-and-suspenders copy. Either way, track one and a track-two mechanism together mean that if OneDrive sync flakes for one user, the org file still loads.

Track 3: Organization Instructions (Claude on the web, Cowork inheritance)

Claude on the web does not parent-walk anything. It reads Organization Instructions set by an Owner in claude.ai/admin. The Anthropic Organization Instructions documentation is short. Maximum three thousand characters. Team and Enterprise plans only. “Up to an hour to take effect across Claude products.” For Owners with admin access, this is a no-brainer.

The job is to condense the SharePoint root CLAUDE.md to about five hundred words covering firm overview, AI policy summary, where to find more, and voice. Paste into the field. Save. Within an hour, every conversation across the org gets it injected silently. No user can disable it.

Organization Instructions apply to every Claude product, so where an Owner has set them they reach Cowork as well. Track three covers Claude on the web AND most of Cowork in one move.

The catch is that this is text, not a file the user can inspect. Owners see it in admin. Users see only the effect. Refresh on a quarterly cadence as the SharePoint root changes, or whenever firm facts shift materially.

Two companions landed on this track since the original post, and together they carry the depth that the three-thousand-character field cannot. Admin-provisioned skills: an Owner uploads each skill as a zip under Organization settings, Skills, and it switches on for every user across web chat, Desktop chat, and Cowork, no hosting and no fetching. And the Microsoft 365 connector, which lets a chat session retrieve a named file from the SharePoint library on demand, read-only, under the user’s own permissions. The pattern that works: the pasted field carries the always-on core and tells Claude to pull department files through the connector when a task needs them. Always-on context stays small and cheap; depth bills only when used.

Track 4: Cowork user onboarding (the residual gap)

Cowork has its own per-user Global Instructions panel. Track three reaches Cowork via Org-level inheritance, but for full coverage, ask each user to paste a five-line summary into Cowork’s own settings. One-time, takes about five minutes per user, and gives Cowork a tighter grip on firm context for the agent’s local actions.

This is the only track that requires a user to do something. The five lines fit on a one-page user onboarding sheet that drops into a wiki or the User Guide tab of a planning doc.

Three of the four are invisible to users

Look at where the visible work happens. Track one: zero user action, parent-walk is silent. Track two: zero user action, IT pushes the file system-wide. Track three: zero user action, the Owner sets it in admin and it propagates. Track four: one paste, once, when a user first opens Cowork.

After tracks one through three are deployed, end users do not need to know the SharePoint root exists. Engineers run Claude Code from anywhere and pick up the file via parent-walk or the system policy path. Knowledge workers open Claude on the web and get firm context injected silently. Only Cowork asks them to act, once.

That is the user-experience win. Single source of truth, four invisible loaders, one short user onboarding step.

Loading by who you are, not just where you are

Here is the gap the four tracks leave open. Every one of them loads context by location or loads it uniformly. Track one fires on whatever folder you start Claude Code in. Track two loads the same org file on every machine. Track three is one Organization Instructions field that every person gets identically. None of them hand you your team’s file because of who you are.

That distinction matters more than it sounds. The parent walk is keyed to filesystem position, not identity. Anthropic’s memory docs describe it as walking up from the working directory and concatenating what it finds, so a finance analyst and a sales rep who start Claude Code in the same folder get the same files. Server-managed settings are blunter still. The docs say plainly that settings “apply uniformly to all users in the organization. Per-group configurations are not yet supported.” So the newest, slickest delivery channel cannot yet give Finance a different child file from Sales.

On the coding surface you can close that gap yourself with a SessionStart hook. A SessionStart hook runs when a session begins, and the hooks reference notes the one property that makes it the right tool for this: “Any text your hook script prints to stdout is added as context for Claude.” So a small script can work out which team the user is on, read that team’s CLAUDE.md, and print it. The model gets the team child stacked on top of the always-on org parent, no folder gymnastics required.

Working out “which team” is the part that reaches into your identity stack, and the wiring is already there. The directory group is the source of truth, and Claude binds to it for roles today: SCIM provisioning maps IdP group membership to role and seat and keeps it fresh on its own. The hook reads the same group signal and maps it to a file. Here is the whole thing, cut down to the parts that carry weight.

Register the hook in settings:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup",
        "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/load-team-context.sh" }]
      }
    ]
  }
}

The script loads the parent, resolves the group, then loads the child:

#!/usr/bin/env bash
# Resolve the user's team from their directory group, then print that team's
# CLAUDE.md. SessionStart sends whatever a hook prints to stdout into context.
set -euo pipefail

LIBRARY="${CLAUDE_GOV_LIBRARY:-$HOME/Documents/Departments}"   # read-only governance library
MAP="$LIBRARY/REFERENCE/team-map.txt"                          # one row: group  team-file

# Always load the org-wide parent first. The guardrails are never skipped.
cat "$LIBRARY/CLAUDE.md"

# Resolve a directory-group signal. In a managed fleet this is the IdP group
# (an env var set at provisioning, or the output of `id -Gn`). Take the first
# group that looks like a team.
group="${CLAUDE_TEAM_GROUP:-$(id -Gn | tr ' ' '\n' | grep -m1 -- '-team$' || true)}"

# Map the group to a team file and print it as the child layer.
child="$(awk -v g="$group" '!/^#/ && $1==g {print $2; exit}' "$MAP" 2>/dev/null || true)"
if [[ -n "$child" && -f "$LIBRARY/$child" ]]; then
  printf '\n'
  cat "$LIBRARY/$child"
fi

And the map is a flat lookup, one row per group:

# directory group   team CLAUDE.md (relative to the library root)
finance-team        Finance/CLAUDE.md
sales-team          Sales/CLAUDE.md
operations-team     Operations/CLAUDE.md
it-team             IT/CLAUDE.md

Two things to notice. The script loads the org parent every single time before it looks at the group, so the firm-wide guardrails never depend on the user being on a recognised team. And the group lookup is doing the job the settings plane cannot do yet, which is the per-team routing. The team files it points at are the same two-level layout from the hierarchy post and the folder tree below: one parent, one child per team, REFERENCE files pulled in via @.

To put this in front of everyone without touching a single laptop, push the hook through the same server-managed settings console from track two. The docs confirm the console carries hooks, not just permission rules. One wrinkle is worth saying out loud: because a hook runs a shell command, each user sees a one-time security approval dialog the first time the managed hook lands, and the session exits if they decline. Warn people it is coming and it stays a non-event.

Now the limits, because none of this is magic. It works on Claude Code and the CLI, and there it stops. The chat surfaces give you no hook to hang it on, so on Claude for the web your parent is the single Organization Instructions field and your child is a per-team Project that someone opens by hand. CLAUDE.md is also context, not enforcement. The Anthropic docs are blunt that the model reads these instructions and is not bound to follow them, so the hook loads the team playbook, it does not police it. And the group-to-file map is yours to own. SCIM keeps the membership current, but the mapping from a group to a file is a thing you maintain, and it drifts the day a team reorganises. None of that sinks the pattern. It means what you are building is identity-aware context provisioning on the one surface that supports it, not a company-wide guarantee. That is the real state of the art, and it is already enough to separate a user who re-explains their team every morning from one who never has to. How each of the four major platforms resolves who you are, and why none of them load instructions from it, is its own topic: your AI has no whoami.

Where the content lives and how to lift it there

The bit I like about getting this layout right the first time is that it stays right for years. If you have not yet sorted out where files live for AI at all, the SharePoint and OneDrive choices upstream of this, do that first. The CLAUDE.md layer assumes the file layout is settled.

The folder pattern is small. One CLAUDE.md at the document library root. A REFERENCE/ directory beside it for shared skills, glossaries, and reusable assets. Per-team subfolders, each with their own narrower CLAUDE.md that pulls in root content via @-import. Keep the layout proper boring. Boring is the goal here, not a failure of imagination.

SharePoint document library
└── Departments/
    ├── CLAUDE.md                  ← the canonical root file
    ├── REFERENCE/
    │   ├── glossary.md
    │   ├── products.md
    │   ├── plants.md
    │   ├── erps.md
    │   └── skills/
    │       ├── voice-profile.md
    │       └── meeting-prep.md
    ├── Finance/
    │   └── CLAUDE.md              ← team overlay only
    ├── Sales/
    │   └── CLAUDE.md
    ├── Operations/
    │   └── CLAUDE.md
    └── IT/
        └── CLAUDE.md

Each team’s overlay file starts with @-imports back to the root and the relevant REFERENCE files, then adds team-specific content underneath. Worked example for a Finance subfolder:

@../CLAUDE.md
@../REFERENCE/glossary.md

## Finance team context

[Finance-only content here, deduplicated from root]

Anthropic’s docs note the recursion limit is four hops, and the first time a session resolves a new @-imported file, the user sees an approval dialog. The 200-line size guidance per CLAUDE.md, repeated across the docs, is real. A 1,500-line root file hurts adherence even if it loads correctly. Better to keep the root tight and push deep content into REFERENCE files that subfolder CLAUDE.md files import on demand.

There are four content categories worth thinking about separately when you sit down to do this work the first time.

Firm-wide content lifted into the root. If a finance subfolder already has a CLAUDE.md, half of it is probably firm-wide. Products, plants, ERPs, glossary, hierarchy, AI policy, communication norms. None of that is finance-specific. Lift it up to root. Leave the finance-only content (close cycle, FP&A tools, finance vendors) in the team file. Use @-import to stitch them. Run this exercise once per team subfolder that already has a CLAUDE.md, and after a couple of teams the root file converges.

Organization Instructions text. Take the root file. Cut to about five hundred words. Drop the deep technical detail and the per-team pointers. Keep firm overview, AI policy summary, where-to-find-more, voice. Paste into claude.ai/admin. The condensed version is what reaches Claude on the web and Cowork via track three. It does not have to match the root word for word. It has to match the root in spirit.

MDM payload for the system policy path. This is just the root file, byte-for-byte, dropped at the system policy path on every machine via Intune or Jamf or Group Policy. No transformation. The Intune package is a tiny installer that copies one file. Detection rule: hash match. When the root changes materially, re-push. Monthly cadence works for most firms.

Cowork onboarding paste. Five lines, summarising the firm, the default tool (Claude only), the default connectors, and the escalation path for sensitive data. The user pastes it into Cowork’s Global Instructions. Document the five lines in your wiki. New hires hit the same paste during onboarding.

Need help getting this right across four loaders the first time? Blue Sheen takes on this kind of architecture work.

Caveats, gotchas, and the contrarian view

I’m not convinced any rollout I have seen got all of these right the first time. A few things will bite if you do not look for them.

The link-fetch path is a dead end. Stop trying it. The instinct that survives every architecture review is “can’t we just give Claude the SharePoint link?” No. We put this on screen with an infrastructure team in June 2026 and watched it fail every way it can fail. A standard sharing link renders SharePoint’s viewer chrome, not the raw file, and Claude’s fetch sees the same thing. Appending &download=1 doesn’t bypass it. The download.aspx?SourceUrl= surgery streams raw bytes only inside a browser that already holds a Microsoft session; in a clean session, which is what Claude’s fetcher is, it gets the Entra sign-in page. OneDrive’s “Anyone” links come closest, and they carry a forced expiration date, so nothing permanent can hang off them. And in any org working toward NIST alignment or holding a cyber-insurance attestation, “Anyone with link” is disabled at the tenant level deliberately, which closes the whole category. The lockdown is correct. Design with it: paste the root (track three), provision the skills, and let the connector fetch depth on demand under real auth. Anything built on an unauthenticated link fetch is a rollout that dies in the security review.

OneDrive Files-on-Demand. OneDrive’s default mode marks files online-only, which means they sit on disk as zero-byte placeholders until first access. If your CLAUDE.md is a placeholder, Claude Code reads the placeholder stub, not the real file. The fix is to mark the Departments folder “Always keep on this device” for all Claude Code users, or to push that setting via Intune. Microsoft’s Files-on-Demand reference is the source for the per-folder behaviour. This is also why track two matters even if track one is healthy. The system policy path does not depend on OneDrive sync at all.

Sync conflict renames. If two users edit the SharePoint root file at roughly the same time, OneDrive will rename one copy CLAUDE-Amit.md and leave the other as the canonical. Once a CLAUDE-Amit.md exists in the synced library, every Claude Code session that walks past it will load it too, and the conflict copy becomes part of context. That is a kludge waiting to happen. The real fix is to make the SharePoint root file read-only at permission level. Designate one owner who edits it and one process that propagates downstream. Editorial conflict turns into a permission denial, which is the right error to get.

Block-level HTML comments are stripped from CLAUDE.md. Block comments like <!-- maintainer note: refresh quarterly --> are removed before context injection. Useful for maintainer notes that should not burn context tokens, and worth knowing if you wonder why your “TODO refresh by Q3” line is not influencing the model’s behaviour. The model never sees it. Inline notes that you want the model to read have to be plain prose.

Server-managed settings are a client-side control, not a vault. The console push is the easy delivery path, but the docs spell out its edges. On an unmanaged device a user with admin rights can edit the cached settings, though the correct version restores on the next server fetch. On a cold first launch there is a brief window before settings load where the policy is not yet enforced. Set forceRemoteSettingsRefresh: true if that window is unacceptable and you would rather the CLI refuse to start than run unprotected. And the whole channel is bypassed if someone points Claude Code at a third-party provider like Bedrock or Vertex. For enforcement that survives all three, that is when the MDM file from track two earns its keep.

Track one + track two is not optional. A common rollout pattern is to deploy only one of these. Why does the one-track rollout always backfire? Because each surface has its own loader, and skipping any one of them leaves the gap visible. Track one alone fails for any user not running Claude Code from a synced subfolder (someone working in ~/code/quick-script/, for example). Track two alone fails to give per-team subfolder overlays. Together they cover the messy middle, and the cost of running both is one extra Intune package nobody notices.

CLAUDE.md is context, not enforced configuration. This is the one most people miss. The Anthropic docs say it directly: instructions in CLAUDE.md arrive in the model’s context as a user message, not as a system prompt or a hard-coded rule. The model reads them. The model does not have to obey them. So what do you do for things that must run, like a pre-commit check or a banned-tool list? Use hooks or permissions.deny in the managed settings file. For rules that live outside Claude, build out a custom MCP server. CLAUDE.md is for guidance and context, not for hard enforcement.

Same logic applies to the size guidance. A 1,500-line CLAUDE.md is not “more rules” for the model. It is a longer block of context that is harder for the model to attend to. Trim aggressively. Keep the root file focused on facts about the firm and high-level policy. Push specifics into REFERENCE files that get imported on demand, or into hooks if they really must run.

Subdirectory loading is on-demand. Per the Landgraf quote earlier, subdirectory CLAUDE.md files only load when the session touches files in that subdirectory. This is fine for most projects but worth noting if you have a deeply nested team structure. A finance analyst running Claude Code from Departments/Finance/Q3-Close/ will get the root file, plus the Finance overlay, plus the Q3-Close overlay if there is one. Move into a different subfolder mid-session and the relevant CLAUDE.md will load when the session next touches a file there. This is a feature, not a bug, but it is also why size discipline at every level matters.

In building Tallyfy, the version of this problem that bit hardest was not loading. It was drift. The root file was right when we wrote it. Six months later half of it was stale. From the engagements I’ve run since, drift is the part that catches every team off guard, because the file looks fine until it doesn’t. The fix is fairly small. Schedule a quarterly review on the calendar, refresh the root, regenerate tracks two and three, and move on.

Where firm context is the kind of thing a compliance audit will care about, drift is itself a finding. The audit trail is the file’s git history if you keep the canonical in a repo, or SharePoint’s version history if you keep it in the document library. Either is fine. Pick one and stick with it.

What this looks like once it works

The more I look at it, the more this stops feeling like architecture and starts feeling like plumbing nobody notices. What does this actually look like once it is running? The whole architecture comes down to a small picture. SharePoint root as the canonical file. Four parallel loaders pulling from it. Three of the four invisible to users. One five-minute paste to round it out.

For engineers, Claude Code starts and the firm context is just there. Same on Claude Desktop when invoked from a project directory. For knowledge workers using Claude on the web, every conversation arrives with org context already injected, no thinking required. For Cowork users, one onboarding step gives the agent the same shape of context it needs to actually do the thing you asked for. Across all four surfaces, the conversations no longer start with “let me explain what we do”. They start with the work.

None of this is a Claude product limitation. Each surface picks up instructions in the way it was designed to. I said earlier that the layout-first instinct produces a CLAUDE.md that loads nowhere. That undersells the loss. The deeper cost is months of repeat context-setting per user per session, all of which compounds before anyone notices the gap, and by the time someone audits it the firm has shipped a hundred small inconsistencies. The architecture is small. The plumbing is small. What matters is actually deploying all four tracks. Skipping any one of them leaves a surface that does not see the source of truth, and once that gap exists, drift is inevitable.

The cleanup is also small once the architecture is in place. Quarterly refresh of the root file. Re-push tracks two and three. Update the onboarding doc when firm facts change. That is the running cost. Smaller than most firms expect, and the reduction in repeat context-setting per session usually pays it back inside a quarter.

If your firm is rolling out Claude or another AI platform across multiple teams and you want one source of truth to actually land in every session, this is the kind of architecture work Blue Sheen does. The plumbing is small. Getting it right the first time saves the rebuild.

Amit Kothari is a managing partner at Blue Sheen, and writes at amitkoth.com about AI in operations and the work of getting it into real organizations.