How to share Claude Code configuration across your engineering team

Every developer on your team using Claude Code has their own CLAUDE.md, their own .claude/settings.json, their own tool permissions. There is no standard. There is no consistency. And nobody knows what anyone else's AI agent is actually configured to do.

This becomes a real problem at around 5-10 developers. You start to see:

• New engineers spend an hour copying someone else's CLAUDE.md via Slack
• Someone updates a shared prompt pattern and has to manually notify the team
• Your CISO asks "what are your AI agents allowed to do?" and you have no single answer
• A contractor leaves and you realize they had custom hooks that nobody else has

The good news: this is a solved problem. Here is how to approach it, from simple to robust.

The most basic approach is to keep a canonical CLAUDE.md in a shared repository — often your main monorepo or a dedicated engineering-standards repo.

Developers copy it locally when onboarding, or symlink it from a checked-out copy:

# From your home directory, symlink to the org's canonical CLAUDE.md
ln -s ~/org/standards/CLAUDE.md ~/projects/my-repo/CLAUDE.md

Works well for: teams under 10 people, simple text instructions in CLAUDE.md, infrequent config updates.

Breaks down when: you need to push updates to everyone, manage settings.json permissions, handle per-platform configs (Cursor vs Claude Code vs Copilot), or track who's running what.

Many teams already use dotfiles repos to share shell configs, vim settings, and other tooling. The same pattern works for Claude Code:

# In your team dotfiles repo
dotfiles/
├── claude/
│   ├── CLAUDE.md          # Org-wide agent instructions
│   ├── settings.json      # Approved tool permissions
│   └── commands/
│       ├── review.md
│       └── deploy.md
└── install.sh             # Symlinks to ~/

Claude Code reads CLAUDE.md from the project root, but also picks up configurations from ~/.claude/settings.json at the user level. A dotfiles setup can populate both.

Works well for: teams already using dotfiles, developers who want to customize on top of the org baseline.

Breaks down when: you need to enforce (not just suggest) configurations, update configs across 50 developers, or have security teams asking for audit trails.

GAL was built specifically for this problem. It gives you a central dashboard where an admin sets the approved Claude Code configuration for the entire organization, and every developer pulls it with one command:

npm install -g @scheduler-systems/gal
gal auth login
gal sync --pull

The sync copies the organization's approved configuration to the developer's local environment — CLAUDE.md, .claude/settings.json, custom commands, hooks, and MCP server configurations.

When the platform team updates the approved config, every developer gets it on their next gal sync --pull. No Slack messages, no manual copying.

GAL also works across AI coding agents — the same sync mechanism handles Claude Code, Cursor, GitHub Copilot, Gemini CLI, and Codex.

Whether you use a git repo, dotfiles, or GAL, here is what a good shared Claude Code configuration covers:

CLAUDE.md — project context and working norms

• Architecture overview: "This is a Next.js app with a separate Express API. The auth layer is in packages/auth."
• Testing standards: "All tests use Vitest. Run pnpm test before committing."
• Code style: "TypeScript strict mode. No any types. Prefer functional components."
• Agent behavior: "Be concise. No explanatory prose unless asked. Always show code, not descriptions of code."
• Security rules: "Never hardcode secrets. All secrets from environment variables only."

settings.json — tool permissions

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(pnpm *)",
      "Bash(make *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl * | bash)"
    ]
  }
}

Custom commands — team workflows as slash commands

If your team has standard workflows (code review format, PR creation, deployment checklist), encode them as custom Claude Code commands in .claude/commands/. Everyone gets the same workflows, consistently applied.

Syncing configuration is different from enforcing it. A sync approach (including GAL's current sync feature) distributes the approved config. A developer can still override it locally.

For many teams, sync is enough — most developers will follow what's provided, and the friction of overriding is enough deterrent.

For teams with strict compliance requirements (SOC 2, ISO 27001, financial services, healthcare), enforcement becomes necessary: the agent's configuration cannot be overridden without admin approval. This is the next layer beyond config sync.

The practical starting point for most teams is sync — it solves 80% of the consistency problem with minimal friction. Build the habit first, then add enforcement when compliance demands it.

The simplest path forward depends on your team size and how much consistency you need today:

• 1-5 developers: Put your CLAUDE.md in the monorepo. Keep it updated in the same PR workflow as your other documentation.
• 5-20 developers: Create a dotfiles or standards repo. Write an onboarding script that sets up new developers with the baseline config.
• 20+ developers or compliance requirements: Use GAL. The overhead of manual sync breaks down at this scale, and your CISO will eventually ask for audit trails.

If you're using GAL, start at gal.run. Setup takes about two minutes: install the CLI, connect your GitHub organization, upload your approved configuration, and run your first sync.