Claude Code for teams: how to roll it out with shared settings

How do you roll out Claude Code for teams?

To roll out Claude Code for teams, give everyone a seat and the same login method, commit the project's shared setup to the repository (a CLAUDE.md, a .claude/settings.json, and any skills or MCP servers), and use managed settings for the rules that must apply on every machine. Start with one team on one real repository, then widen.

The pieces fit in layers. The repository carries what a project needs. Managed settings carry what the organization requires. Each developer keeps personal preferences in their own files. This guide walks through each layer in the order you'd set it up. If you're an administrator planning a large deployment, the Claude Code enterprise guide goes deeper on policy and data handling.

How do teammates get access and sign in?

Most teams use a Claude for Teams or Enterprise plan. The authentication docs call it "recommended for most teams," and the admin guide calls it the default recommendation. Other options are the Claude Console for pay-as-you-go API billing, or Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry if you want to stay inside an existing cloud account.

On seats, Anthropic's help article for Team and Enterprise plans says "Claude Code is included with every Team plan seat." On older Enterprise plans, only some seat types include it, so check before you invite people.

Each developer then:

1. Installs Claude Code and runs claude.
2. Runs /login first if they're signed in with another account.
3. Chooses the Claude account with a subscription, selects the Team or Enterprise organization and clicks Authorize.

If the organization option doesn't show up, they should run /logout, then claude update, restart the terminal and sign in again. Some features, including cloud sessions, Code Review and Remote Control, need a claude.ai account, so teams on a cloud provider may also want Team or Enterprise seats for those.

What should every repository share?

This is the layer that makes Claude Code feel consistent across a team. All of it lives in git, so it reaches everyone who clones the repo.

Start with CLAUDE.md. Run /init and Claude analyzes the codebase and writes a starting CLAUDE.md with the build commands, test instructions and conventions it finds. Then edit it down to what Claude wouldn't discover by itself. The memory docs suggest focusing it on "project-level standards rather than personal preferences." The CLAUDE.md guide has examples.

Then commit .claude/settings.json. The settings docs put it simply: "Commit .claude/settings.json so everyone who clones the repository gets the same permissions, hooks, and plugins." A small starting file might allow the project's scripts, ask before pushes and block secrets:

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Two things to tell your team about this file. Allow rules and marketplace entries only take effect after each person trusts the folder, while deny and ask rules apply in every session. And anyone can override settings for themselves in .claude/settings.local.json; Claude Code adds that file to their global git excludes the first time it writes it.

How do you share plugins and skills with the team?

Plugins bundle skills, agents, hooks and MCP servers so a team installs them as one unit. They come from a marketplace, which is a catalog Claude Code fetches from a git repository, a URL or a local path.

To make a repository's contributors use your team's marketplace, add two keys to its committed .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/claude-plugins" }
    }
  },
  "enabledPlugins": {
    "code-formatter@acme-tools": true
  }
}

extraKnownMarketplaces registers the marketplace and enabledPlugins names the plugins as plugin-name@marketplace-name. If the marketplace repo is private, each person needs read access to it. A plugin that the marketplace lists by its own external source doesn't install from repository settings alone; each contributor runs claude plugin install <name>@<marketplace> --scope project once. The plugins for organizations docs cover the details, and the plugin marketplace guide explains how to build one.

For lighter needs, commit skills directly under .claude/skills/ in the repo. Anthropic's skills docs say to "Commit it so your team gets it too."

When do you need managed settings?

Repository settings are suggestions a developer can override locally. When something must hold on every machine, such as blocking secret files, requiring your organization's login or disabling bypass mode, use managed settings. They sit at the top of the precedence order: managed, then command line, then project local, then shared project, then user.

You can deliver them three ways:

• Server-managed settings from the claude.ai admin console. No MDM needed; Claude Code fetches them at startup and refreshes hourly. Requires a Teams or Enterprise plan and the Owner or Primary Owner role to edit.
• MDM policies: a com.anthropic.claudecode plist on macOS or a registry policy on Windows.
• A managed-settings.json file at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, or C:\Program Files\ClaudeCode\ on Windows.

By default only one managed source applies on a machine, checked in that order, so if you use server-managed settings, don't expect a file-based policy to add to it. List settings such as permissions.deny merge across all levels, so developers can add entries but not remove yours.

A common team policy restricts login to your organization and blocks risky actions:

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"],
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"],
    "disableBypassPermissionsMode": "disable"
  }
}

Login restrictions are a special case. Server-managed settings only reach accounts already signed in to your organization, so they can't redirect someone's first login; deploy forceLoginMethod and forceLoginOrgUUID through device management as well. The admin setup guide maps out every control, and the permissions guide explains rule syntax.

You can also deploy organization-wide instructions as a managed CLAUDE.md. Anthropic's docs draw the line clearly: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer."

What does a sensible rollout plan look like?

1. Pick a pilot. One team, one real repository you know well.
2. Set up the repo. Generate and trim a CLAUDE.md, commit .claude/settings.json with permissions, and add the skills or plugins the team already relies on.
3. Add policy before the first session. Login restrictions and deny rules go in managed settings, not in CLAUDE.md.
4. Verify on one machine. Ask a developer to run /status and check the Setting sources line, then /plugin to confirm the marketplace and plugins arrived.
5. Point people at training. The admin guide links Anthropic's free Claude Code 101 course on Claude Academy.
6. Watch usage. On Team and Enterprise plans the analytics dashboard is at claude.ai/analytics/claude-code; OpenTelemetry export works on every provider.
7. Widen in waves. Fold what the pilot learned back into the shared files, then add the next team.

Where do shared prompts fit?

Not everything a team reuses belongs in a plugin. Many teams also keep a set of prompts for reviews, migrations or incident write-ups. Kipt keeps prompts and Agent Skills as Markdown in a private GitHub repo you own, and installs every skill into Claude Code with npx skills add https://github.com/<you>/<repo>.git --all -g. If your managed settings turn on strictPluginOnlyCustomization, skills from user and project sources are blocked, so in that case ship shared skills as a plugin instead.