Claude Code for teams: what a rollout actually configures

01 / Plans

What a plan decides before anything else

Claude Code runs the same on Pro, Max, Team, and Enterprise. What changes is the administrative surface around it. The feature availability page publishes a per-plan matrix, and the rows below are the ones that decide whether a team rollout is possible at all, read on August 24, 2026.

The organization-level version of this question, with what each vendor does and does not offer, is in How to manage AI skills across an organization.

02 / Settings

The five layers a Claude Code setting can live in

Claude Code reads settings from four files plus whatever your organization delivers as managed policy. When the same key appears in more than one, the highest layer that sets it wins. The list below is in precedence order, highest first.

The document a team writes once and then points every settings file at is in AI coding guidelines template.

03 / Conventions

Where a team convention goes, and what actually enforces it

CLAUDE.md is the file teams reach for first and the one they most often put in the wrong scope. Anthropic documents four locations plus two keys, in load order from broadest to most specific, so a project instruction lands in context after a user instruction.

How the project file relates to the other convention file teams commit is in AGENTS.md vs SKILL.md.

04 / Skills

The places a Claude Code skill can come from

A skill is a folder with a SKILL.md inside it, and where you put the folder decides who has it. Anthropic publishes four locations plus three more ways a folder reaches a session, and the precedence between them is not the one a team would guess.

The authoring rules for the file itself, field by field, are in How to write a SKILL.md file.

05 / Plugins

How a plugin reaches everyone without anyone installing it by hand

A plugin is the only mechanism that carries skills, subagents, hooks, commands, and MCP servers in one package, which makes it the unit a team distributes once a second repository appears. There are two halves: registering the marketplace, and enabling the plugins inside it.

How a plugin differs from the skill it contains, and when a team needs each, is in Claude skills vs plugins.

06 / MCP

Which MCP scope your team is actually sharing

MCP servers have their own scope system, separate from settings and from skills, with its own file and its own precedence order. Only one of the three developer scopes is shared with the team, and it is not the one called local.

The version of this with one MCP endpoint in front of the whole team library is in Set up a shared MCP skill library for teams.

07 / Trust

What a cloned repository does not give a teammate on the first run

This is the section to read before you blame your configuration. Content that a repository supplies is held back until the person accepts the workspace trust dialog for that exact folder, and two situations never show that dialog. The rows below are Anthropic's own table, with the two columns being trusting only a parent folder and running claude -p or the Agent SDK in a folder that was never trusted.

Which other clients read the same folders your team is committing is in Agent Skills support: which AI clients read SKILL.md.

08 / Rollout

A rollout in the order that avoids rework

Seven steps, in the order that stops you from redoing the previous one. The first four are decisions, the last three are files. A team that already runs Claude Code individually can start at step three.

1. 01

   Confirm the plan carries what you are about to rely on

   Server-managed settings, the analytics dashboard, SSO, and Code Review exist on Team and Enterprise and not on Pro or Max. On an older Enterprise plan, check the seat type: Claude Code needs a Chat + Claude Code seat or a Premium seat there, while new and self-serve Enterprise plans include it with the single seat. Get this wrong and steps two and seven have nothing to run on.

2. 02

   Choose how managed settings reach machines, or decide not to have any

   Server-managed settings need only the Owner or Primary Owner role and the claude.ai console, and they reach cloud sessions. An MDM plist or HKLM registry policy resists tampering because writing it takes admin rights, and it works on any provider. A file at /etc/claude-code or the macOS equivalent is the simplest to script. Claude Code applies the first source that delivers at least one policy key, so pick one as the primary and treat the rest as fallback.

3. 03

   Decide what is policy and what is guidance

   Tools, commands, paths, sandboxing, login method, and model restrictions are settings keys and are enforced by the client. Code style, review expectations, and data-handling reminders are CLAUDE.md and are followed rather than obeyed. Write the list in two columns before writing any JSON, because moving an item later means moving it between two different delivery mechanisms.

4. 04

   Commit the shared settings file first, and start with deny

   Deny and ask rules apply on a fresh clone with no trust step, so they are the part of the file that works on day one. Allow rules and extraKnownMarketplaces entries wait for each person to trust the folder. Put the deny list, the ask list, the env block, and the hooks in .claude/settings.json, commit it, and tell people the first run will show a dialog listing what the repository wants to grant.

5. 05

   Put the conventions where their scope actually is

   One project CLAUDE.md at ./CLAUDE.md or ./.claude/CLAUDE.md for anything repository specific, .claude/rules/ once that file stops being readable, and a managed policy CLAUDE.md only for text that must apply in every repository on the machine. Ask a teammate to run /context and read the Memory files list rather than assuming the file loaded.

6. 06

   Commit the skills and the MCP file the same way

   A skill folder goes in .claude/skills/<skill-name>/SKILL.md and travels with the clone, including into cloud sessions. A shared MCP server goes in .mcp.json at the repository root, and each teammate approves it once in an interactive session. Remember that a personal skill of the same name outranks the committed one, so pick names your team will not shadow by accident.

7. 07

   Move everything that outlives one repository into a plugin

   Declare the marketplace in extraKnownMarketplaces and the plugins in enabledPlugins in the same committed settings file, then expect the first run to print a claude plugin install command rather than installing an external plugin silently. For containers and CI, build a seed directory once and point CLAUDE_CODE_PLUGIN_SEED_DIR at it so nothing is cloned at runtime.

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp"
  },
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/claude-plugins" }
    }
  },
  "enabledPlugins": {
    "code-formatter@acme-tools": true
  }
}

09 / Teams

The half of the rollout that has no setting

Everything above is distribution: getting files onto machines and keeping the wrong ones off. Selection is the other half, and it is knowing which skill to reach for and why that one. Claude Code has an excellent answer to the first and, by Anthropic's own account, none to the second.

Install the plugin

Run /plugin marketplace add TommyBez/skillsboard and then /plugin install skills-board@skills-board, and Claude Code has the team library in session. The install is per user, not per team: committing the marketplace in extraKnownMarketplaces and the plugin in enabledPlugins makes every fresh clone prompt each teammate with that exact install command on the first run, and the seed directory provisions it without a prompt in containers and CI, exactly as the plugins section above describes.

Or point one MCP endpoint at it

Skills Board is reachable as a Streamable HTTP MCP server at https://www.skillsboard.sh/api/mcp, with browser sign-in and no API key to copy. Added with claude mcp add --scope project it lands in the committed .mcp.json and every teammate approves it once; added at user scope it follows one developer across every repository.

Open the original source

Every saved skill records the repository and the path it came from, so a teammate can read the SKILL.md, and anything in scripts beside it, before the folder goes anywhere Claude Code scans. That is the read that matters most for a skill with allowed-tools in its frontmatter, because workspace trust never gates that field.

Copy an install command or download a ZIP

The command is npx skills add for the saved source, and the ZIP is the latest files available from the source at download time, for anyone who would rather place the folder in .claude/skills by hand. Both sit beside the plugin and MCP routes rather than instead of them.

• Saving a skill records that a team has it in use. It is not a security review, an approval, or a license opinion, and it is a team's own choice rather than a verdict on the code.
• Skills Board follows the latest version available from the saved source. Saved skills track the source; a published collection release pins the commit it was built from.
• Saving a skill does not install it. The folder still has to land in a directory Claude Code scans, by the plugin, by the CLI, or by hand.
• An MCP connection cannot install or run a skill, and it cannot edit or delete saved team skills.
• None of this replaces managed settings. Policy enforcement is the client's job, and no external service can substitute for a permissions.deny rule.
• The hosted product is free forever, the code is MIT licensed, and you can read or self-host all of it.

A worked shortlist, with the selection criteria written down rather than implied, is in The best Claude skills, with the criteria used to pick them.

10 / Limits

What the documentation does not answer

Six things a team rollout runs into that Anthropic's pages either leave open or answer in two places that disagree. Each is stated as an absence rather than filled in with a guess.

11 / Questions

Frequently asked questions

Does Claude Code come with a Team plan seat?

Yes. Anthropic states that Claude Code is included with every Team plan seat, with premium seats carrying more usage for heavier workloads. On new and self-serve Enterprise plans it is included with the single seat. On older Enterprise plans it needs a Chat + Claude Code seat or a Premium seat instead.

How does a team share Claude Code settings?

Commit .claude/settings.json at the repository root. Everyone who starts Claude Code in that folder gets the same permissions, hooks, environment variables, and plugin declarations, and so does a cloud session that clones the repository. Each teammate can still override it for themselves in .claude/settings.local.json, which Claude Code keeps out of git.

Where do team skills go in Claude Code?

In the project skills directory, .claude/skills, one folder per skill with a SKILL.md inside it. That folder travels with every clone, including into cloud sessions. For skills that outlive one repository, put a skills directory in a plugin and declare the marketplace in the committed settings file instead.

How does a team share an MCP server in Claude Code?

Use project scope. Run claude mcp add --scope project, or add the entry under mcpServers in .mcp.json at the repository root and commit it. Each teammate approves the server once in an interactive session. Local and user scope both live in ~/.claude.json and are never shared with anyone.

What is the difference between CLAUDE.md and managed settings for a team?

Enforcement. Anthropic writes that settings rules are enforced by the client regardless of what Claude decides to do, while CLAUDE.md instructions shape behavior without being a hard enforcement layer. Put blocked tools, commands, paths, and login restrictions in settings, and put code style, review expectations, and compliance reminders in CLAUDE.md.

Can an admin lock down what Claude Code loads for the team?

Yes, from managed settings and nowhere else. strictPluginOnlyCustomization limits skills, agents, hooks, and MCP servers to plugins and managed sources, strictKnownMarketplaces allowlists the marketplace sources people may add, allowManagedPermissionRulesOnly drops every permission rule that is not managed, and a managed-mcp.json with an empty server map turns MCP off entirely.

Why do the permission rules my team committed not apply after cloning?

Workspace trust. Allow rules and additionalDirectories from a repository settings file are held until the person accepts the trust dialog for that exact folder, and a claude -p or Agent SDK run never shows the dialog. Deny and ask rules are unaffected and apply in every session, trusted or not.

Sources

Editorial method: every claim about how Claude Code behaves for a team comes from the first-party documentation below, fetched on the date at the top of this page. Where two Anthropic pages disagree, this page names the disagreement instead of picking quietly. Product behavior changes, so check the linked pages before you rely on a detail.

• Set up Claude Code for your organization

  The decision map for a rollout: provider, delivery mechanism, what to enforce, usage visibility, data handling, and the verify step with /status.

• Claude Code settings

  The four settings files, who each one reaches, the five-layer precedence order, and the list-merge rules.

• Claude Code settings reference

  Every key with its scope, including strictPluginOnlyCustomization and its four surface sub-keys.

• Example settings files

  A team's shared settings file, published as a copyable JSON document with the three caveats that precede committing one.

• Deploy managed settings

  The four delivery mechanisms with their file paths, precedence within the managed tier, and what a developer can still change.

• Configure server-managed settings

  Delivery from the claude.ai console: the plan requirement, the Owner or Primary Owner role, hourly refresh, and the cloud-session reach that endpoint-managed settings do not have.

• How Claude remembers your project

  The CLAUDE.md scope table, the managed policy file and the claudeMd key, claudeMdExcludes, and the enforcement versus guidance distinction.

• Extend Claude with skills

  Where skills live, the precedence between the levels, nested and added directories, the three sharing scopes, and what Cowork and cloud sessions do not read.

• Discover and install prebuilt plugins through marketplaces

  The team marketplace section, and the v2.1.195 change that stops an external plugin from installing itself when only project settings enable it.

• Create and distribute a plugin marketplace

  extraKnownMarketplaces and enabledPlugins in a repository, the plugin seed directory for containers, and the managed marketplace restrictions.

• Connect Claude Code to tools via MCP

  The three installation scopes with their storage locations, the precedence order including plugins and connectors, and the approval behavior by session type.

• Control MCP server access for your organization

  The seven restriction patterns, and the statement that Claude Code has no built-in MCP server registry to browse.

• Configure permissions

  Project allow rules and workspace trust, and the table of what a repository supplies before the folder itself is trusted.

• Track team usage with analytics

  The Team and Enterprise dashboard, the metrics it publishes, the GitHub app that contribution metrics require, and the Zero Data Retention exclusion.

• Feature availability

  The per-provider tables and the availability by subscription plan matrix that the plans section reproduces.

• Use Claude Code with your Team or Enterprise plan

  Anthropic help center article dated June 11, 2026: which seat types include Claude Code, IDE coverage, and what happens at the usage limit.