Rolling Out Claude Code to a Team: Settings, Seats and Guardrails

Rolling Claude Code out to a team works best as two layers of configuration and one place for the work. Put the rules that must hold for everyone, such as secrets that are never read and modes that are never allowed, in managed settings, which developers cannot override. Put what the team agrees for a codebase, its permissions, skills and MCP servers, in a .claude/ folder committed to the repository. Allow MCP servers and plugins from a short list. Turn on the usage dashboard or OpenTelemetry before people start, not after. Onboard with a one-page checklist. And have every developer’s Claude Code record its work on the same board, so the team sees tasks, not transcripts.

Seats and sign-in

On Team and Enterprise plans, Claude Code comes with the seat. Anthropic’s help article on using Claude Code with a Team or Enterprise plan↗ (opens in a new tab) says every Team seat includes it and newer Enterprise plans include it with every seat, while some older Enterprise plans use specific seat types; Owners assign seats in Organization settings. Each developer then runs claude, chooses to sign in with their Claude account, and picks the organisation.

• Pin sign-in to your organisation. The forceLoginMethod and forceLoginOrgUUID settings restrict which login method and which organisation Claude Code accepts, so nobody works on company code under a personal account by accident.
• Know what needs a claude.ai seat. If you deploy through Amazon Bedrock, Google Cloud or Microsoft Foundry instead, cloud sessions, Remote Control and Code Review are not available on those credentials alone.
• A developer who sees “You haven’t been added to your organization yet” has a seat without Claude Code access; fix it in the admin console, not on their machine.

Managed settings: where admins put them

Managed settings sit above every other level, and nothing a developer sets overrides them. Anthropic’s guide to setting up Claude Code for your organisation↗ (opens in a new tab) lists four ways to deliver them, checked in this order:

Server-managed    claude.ai admin console: Admin Settings > Claude Code > Managed settings
                  (Team and Enterprise; Owner role; fetched at startup, refreshed hourly)
plist / registry  macOS: com.anthropic.claudecode plist
                  Windows: HKLM\SOFTWARE\Policies\ClaudeCode
File-based        macOS:   /Library/Application Support/ClaudeCode/managed-settings.json
                  Linux and WSL: /etc/claude-code/managed-settings.json
                  Windows: C:\Program Files\ClaudeCode\managed-settings.json
Windows user      HKCU\SOFTWARE\Policies\ClaudeCode (writable without admin rights)

Without device management, server-managed settings are the easy route: no files to deploy, and they reach every machine that signs in to your organisation. With MDM, the plist, the HKLM registry key or the file resist tampering because writing them needs admin rights; the HKCU key does not, so treat it as a default, not a control. The same folders also take a managed CLAUDE.md for organisation-wide instructions that cannot be excluded. To confirm a machine received the policy, have the developer run /status: the Setting sources line shows Enterprise managed settings and which source won.

Permission policy: what to enforce centrally

Keep the managed file short. Enforce only what must never vary between people or repositories, and leave the rest to project settings, where the team can change it in a pull request.

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ],
    "ask": ["Bash(git push *)"],
    "disableBypassPermissionsMode": "disable"
  },
  "disableSideloadFlags": true
}

The deny rules keep Claude’s file tools away from secrets in every repository; the ask rule forces a prompt before anything is pushed, even in auto mode; and disableBypassPermissionsMode stops anyone starting with --dangerously-skip-permissions. disableSideloadFlags rejects the command-line flags that load a plugin, subagent or MCP server for a single run. A deny set here cannot be allowed back at any other level. If you want managed settings to be the only source of permission rules at all, allowManagedPermissionRulesOnly does that, at the cost of every project’s own rules. What each permission mode does, and the rules worth adding per repository, are in Claude Code auto-approve; sandboxing and network allowlists, which close the gap a deny on WebFetch leaves when curl is allowed, are in security controls for AI coding agents.

A shared .claude/ in git

Everything the team agrees for one codebase lives in the repository: CLAUDE.md at the root, .claude/settings.json for permissions, hooks and environment variables, .claude/rules/, .claude/skills/ and .claude/agents/, and .mcp.json for servers everyone uses. It is reviewed like code, so a new allow rule gets a second pair of eyes. Personal overrides go in .claude/settings.local.json and CLAUDE.local.md, which stay out of git. The layout, and what belongs in each file, is in Claude Code project structure.

MCP servers: an allowlist, not a free-for-all

MCP servers are where most of a team’s exposure sits, because each one either runs code on a developer’s machine or receives what Claude sends it. Managed settings can fix the set outright with a managed-mcp.json, or allow a catalogue with allowedMcpServers and block specific servers with deniedMcpServers, matched by URL or exact command rather than by name. The approved list, who may add a server where, and how to enforce it across Claude Code, VS Code and Copilot, is in MCP governance; set it up before the first .mcp.json lands in a repository.

Plugins: a team marketplace

Plugins bundle skills, subagents, hooks and MCP servers, so installing one is installing all of that at once. For a team, publish the plugins you want in your own marketplace repository and control sources centrally. Anthropic’s page on managing plugins for your organisation↗ (opens in a new tab) shows the pattern: extraKnownMarketplaces registers a marketplace on every machine, enabledPlugins installs and enables named plugins from it, and strictKnownMarketplaces allows only the sources you list.

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "anthropics/claude-plugins-official" },
    { "source": "github", "repo": "your-org/*" }
  ],
  "extraKnownMarketplaces": {
    "your-marketplace": {
      "source": { "source": "github", "repo": "your-org/your-marketplace" }
    }
  },
  "enabledPlugins": {
    "code-formatter@your-marketplace": true
  }
}

Adding a marketplace outside the list then fails with a message that it is blocked by enterprise policy. How to install and vet the plugins themselves is in Claude Code plugins. To block one plugin from an allowed marketplace, set it to false in enabledPlugins. For one repository instead of the whole fleet, the same two keys work in its .claude/settings.json once a contributor trusts the folder. How plugins compare with skills and subagents is in plugins vs skills vs subagents.

Seeing usage

There are two instruments, and most teams want both. On Team and Enterprise, the Claude Code analytics dashboard↗ (opens in a new tab) at claude.ai/analytics/claude-code shows adoption, usage and, with the GitHub integration switched on, contribution metrics such as pull requests and lines of code shipped with Claude Code’s help; Admins and Owners can view it. Per-person usage and spend come from the spend report in the organisation’s analytics settings.

For your own dashboards and alerts, Claude Code exports metrics and events through OpenTelemetry↗ (opens in a new tab), turned on with CLAUDE_CODE_ENABLE_TELEMETRY=1 and the standard OTEL_* exporter variables. Put those in the env block of managed settings and every machine reports to your collector without anyone setting anything. What to capture, and how to treat logged prompts, is in AI agent observability.

Onboarding: one page, one week

1. Start with a pilot of three to five people on one repository, with the managed policy already in place. Their friction becomes your checklist.
2. Each person installs the CLI, runs claude, signs in with the organisation account, and runs /status to see managed settings listed as a source. If they are not, stop there and fix delivery.
3. They read the repository’s CLAUDE.md before their first session, so they know what Claude has been told.
4. Their first real task is a small one from the board, done in Manual mode, with the diff reviewed before anything is committed.
5. After a week, collect the corrections people kept typing and turn the repeated ones into lines in CLAUDE.md or rules in .claude/settings.json, through a pull request. Then widen the rollout.

Point new people at Claude Code best practices for habits, and keep the checklist next to the work, not in a wiki nobody opens.

One shared board for the work

With ten developers each running Claude Code, the question stops being “what did Claude do?” and becomes “what is everyone’s Claude doing, and on what?”. Session histories live on each laptop. A shared fenbs board answers it in one place. Commit the server to the repository’s .mcp.json; it holds only the URL, no secret, because each developer signs in through their own browser with /mcp and their Claude Code acts under their own role on the board, narrowed by the scopes they tick. Roles are defined per company by its owner, so a contractor can be given comment-only access while the team can move tasks.

{
  "mcpServers": {
    "fenbs": { "type": "http", "url": "https://fenbs.ai/api/mcp" }
  }
}

Every change is then recorded in the board’s History as Claude acting for a named person, and tasks move through To Do, Next Up, In Progress and Completed whoever or whatever moved them. For a server or CI job that cannot open a browser, issue a token by hand under Settings, with a name, scopes and an optional expiry, and revoke it when the job goes. The CLAUDE.md lines that make each session read the board first and comment when it stops are in a task-tracking workflow for Claude Code.