Claude Code for Teams: A Practical Setup Guide

Adopting Claude Code for teams is less about installing a CLI and more about agreeing on shared conventions. When one developer uses Claude Code, the tool fits itself to their habits over time. When a whole team uses it, the goal flips: you want the agent to behave consistently for everyone, regardless of who is driving. The good news is that almost everything that shapes Claude Code's behavior lives in files you can commit to your repository. This guide covers how teams actually roll it out, from a shared CLAUDE.md to committed commands, agents, permissions, and keeping everyone on a compatible version. If you are new to the tool, start with our overview of what Claude Code is.

Why team setup differs from solo setup

On your own, an inconsistent agent is just an annoyance you tune away over time. On a team, inconsistency compounds. One engineer's Claude Code writes tests with one framework, another's skips them entirely; one respects your import ordering, another reformats half the file. Pull requests start to look like they came from different codebases because, in a sense, they did. The fix is to treat agent configuration as shared infrastructure: versioned alongside your code, reviewed in pull requests, and improved over time like any other part of your toolchain.

Start with a shared CLAUDE.md

The single highest-leverage file when setting up Claude Code for teams is CLAUDE.md at the root of your repository. Claude Code reads it automatically and treats it as standing instructions for the project. Because it lives in the repo, every team member's agent reads the same guidance, and changes to it flow through normal code review. Use it to encode the conventions you would otherwise repeat in every prompt.

• Stack and structure: the frameworks, language versions, and directory layout the agent should assume.
• Conventions: naming, formatting, import ordering, and error-handling patterns specific to your codebase.
• Testing expectations: which test framework to use, where tests live, and when to add them.
• Commands: how to build, test, lint, and run the project so the agent can verify its own work.
• Guardrails: things to never do, such as touching generated files, committing secrets, or rewriting migration history.

Claude Code supports nested memory files, so a monorepo can keep a root CLAUDE.md for org-wide rules and per-package files for local specifics. Teams often also keep a personal, git-ignored memory file for individual preferences that should not be imposed on everyone. Keep the shared file tight and high-signal: a bloated memory file is harder to maintain and easier to ignore. Check the official Claude Code docs for the exact memory file names and precedence, and see our glossary for how memory and context fit together.

Commit the .claude/ directory

Beyond memory, most of Claude Code's customization lives in a .claude/ directory in your project. This is where teams get the most value, because checking it into version control turns one person's clever setup into a shared capability. The typical contents:

Slash commands let you turn a recurring prompt into a reusable shortcut: a /review command that runs your review checklist, a command that updates your changelog in your house style, or a deploy-prep command that runs the right checks. Commit them and the whole team invokes the same tested workflow instead of each person reinventing it. Our guide to slash commands covers how to author them.

Subagents are scoped helpers with their own instructions and tools, useful for delegating focused work like a security pass or a test-writing specialist. Defining them in .claude/agents/ means the agent your teammate triggers is the same one you tuned. The subagents explainer goes deeper on when to reach for them.

your-repo/
  CLAUDE.md                 # shared project memory (committed)
  .claude/
    settings.json           # team settings + permissions (committed)
    commands/
      review.md             # /review
      ship.md               # /ship
    agents/
      test-writer.md        # focused test subagent
  .gitignore                # ignore .claude/settings.local.json

Agree on permissions

Claude Code asks before running tools that can change your system, and you can pre-approve or deny categories of actions in settings. For a team, codifying these in the committed settings.json matters for two reasons: it removes friction (no one re-approves the same safe commands all day) and it sets a security baseline (risky operations stay gated for everyone). A common pattern is to allow read-only and routine project commands broadly while keeping anything destructive or network-touching behind an explicit prompt.

Layered settings make this clean: a committed project file establishes the shared policy, and a local file (ignored by git) holds individual exceptions. That way the team's security posture stays reviewable in pull requests, while individuals still have room to adjust their own machines. If you also use hooks, the same logic applies, commit the ones the whole team should run, such as a formatting hook on file writes. Confirm the exact settings keys and permission syntax against the official docs, since these can change between releases.

Share skills and MCP servers

Two more capabilities are worth standardizing across a team. Skills package reusable expertise, a set of instructions and supporting files the agent can pull in on demand, so domain knowledge that lived in one engineer's head becomes something the whole team's agent can apply. Storing them in the repo means everyone benefits and improvements are reviewed like code. Our skills explainer walks through the format.

MCP servers connect Claude Code to external tools and data: your issue tracker, database, internal APIs, and the like. Defining shared MCP configuration at the project level gives everyone the same integrations without each person wiring them up by hand. Be deliberate about which servers are team-wide versus personal, and keep credentials out of committed files. See how MCP works for the details, and note that MCP setup evolves, so confirm exact config keys against the official docs.

Keep everyone on a compatible version

Shared config only behaves consistently if everyone is running a compatible version of Claude Code. The tool ships frequently, and updates regularly add or change commands, settings keys, skills behavior, and MCP handling. A team split across several versions can hit subtle differences: a setting one person relies on may not exist on a teammate's older build, or a new default changes behavior unevenly. Treat version alignment as part of onboarding and routine hygiene.

• Document the minimum version your committed config assumes in CLAUDE.md or your contributing guide.
• Encourage frequent updates, and read the release notes before adopting config that depends on a new feature, see how to update Claude Code.
• Designate someone to watch releases and flag changes that affect your shared setup, or automate it so no one has to remember.

This is exactly the gap Claude Drops is built to close. It is an independent app and site (not affiliated with Anthropic) that notifies you when a new Claude Code release ships and lets you browse the changelog, so your team can react to changes deliberately rather than discovering them through broken workflows. You can scan the latest release at a glance or read about why tracking releases matters for teams that depend on consistent tooling.

A rollout checklist

1. Write a focused, high-signal CLAUDE.md capturing your stack, conventions, and build/test commands.
2. Commit a .claude/ directory with shared slash commands and any project subagents.
3. Set a team permissions baseline in committed settings.json; keep personal overrides in a git-ignored local file.
4. Move reusable expertise into shared skills and standardize team-wide MCP servers (without committing secrets).
5. Document a minimum Claude Code version and set up a way to track new releases.
6. Review and improve the config in pull requests as your codebase and the tool both evolve.

Done well, Claude Code stops being a personal productivity hack and becomes a consistent member of the team, one that writes code in your style, runs your checks, and respects your guardrails no matter who invoked it. The setup is mostly a one-time investment that pays off on every pull request after. To keep your shared config aligned with new features and avoid surprises, keep an eye on the Claude Code changelog and let Claude Drops tell you when something changes.