Claude Code team setup: shared config and managed settings

Updated October 12, 2026 · 8 min read

A team runs Claude Code in four layers. Each developer gets access through a Claude for Teams or Enterprise seat, or through Claude Console API billing. The repository carries what everyone should share: CLAUDE.md, .claude/settings.json, .mcp.json and the skills and subagents under .claude/. Personal files stay out of git. For the few things that must not vary, an admin uses managed settings.

Agent teams, the experimental feature where several Claude Code sessions work in parallel, are a separate topic with their own section near the end.

Sources are Anthropic’s Claude Code docs as read on 12 October 2026 and a scan of public repositories we ran on 1 October.

How does a team get Claude Code seats?

Anthropic’s authentication page lists six ways for a team to get access: Claude for Teams or Enterprise (which it recommends for most teams), the Claude Console, a self-hosted Claude apps gateway, Amazon Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry.

On Teams or Enterprise, each member gets both Claude Code and Claude on the web, with central billing. Teams is the self-service plan, with admin tools, SSO, billing management and server-managed settings for Claude Code. Enterprise adds domain capture, role-based permissions and the compliance API. Setup takes three steps: subscribe, invite members from the admin dashboard, and have each member install Claude Code and log in with the claude.ai account they were invited with.

The first page of results for this search still shows a thread titled “Claude Code not available on Team plan?!”. It is out of date, since Anthropic’s docs now say Team members get Claude Code. Prices, seat types and usage limits are in our Claude Team plan guide; we did not verify per-seat limits for this page.

The Console route suits teams that want API billing. An admin invites users at platform.claude.com/settings/members and gives each one a role: the Claude Code role can only create Claude Code API keys, and the Developer role can create any kind. From v2.1.242, a Console user can sign in without creating an API key at all.

Developers with a personal and a work account can keep both signed in, one config directory each:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

What should the team commit to the repository?

Anthropic’s .claude directory reference marks which project files to commit. These are the ones a team shares:

Real teams commit less than that. We scanned the 1,000 most-starred GitHub repositories pushed since 1 July 2026 (the smallest has 29,547 stars), and 173 have a .claude directory. Inside it, 124 hold skills, 64 a settings.json, 37 commands, 32 agents, 20 rules and 20 hooks. After CLAUDE.md, then, skills are what teams share most, and shared settings are rarer than you might expect.

For instructions, 259 have a CLAUDE.md at the root, 365 have an AGENTS.md, and 213 have both. Of the 124 that are real files rather than stubs or pointers, the median is 117 lines; 90 give build or test commands, 93 describe the architecture and 99 list things not to do. The full breakdown is in CLAUDE.md examples from top GitHub repos, and the CLAUDE.md guide covers what to write.

A shared settings file usually sets permissions. This shape comes from Anthropic’s settings docs:

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Two rules apply to committed settings. List keys such as permissions.allow merge across files, so a teammate’s own rules add to the team’s instead of replacing them. And some of what you commit waits until each person trusts the folder in Claude Code, so a cloned repository cannot grant itself permissions.

The same trust rule covers .mcp.json. claude mcp add --scope project writes it, and ${VAR} or ${VAR:-default} references keep each person’s API key in their own environment, out of git. In an interactive session, everyone approves each project server the first time, and a cloned repository cannot approve its own: enableAllProjectMcpServers or enabledMcpjsonServers committed to .claude/settings.json is ignored in an untrusted folder. claude -p runs have no prompt, so project servers load without asking. We ran Claude Code headless against Dexio on 26 September 2026 with the server defined at project scope. Scopes and approval are covered in our Claude Code MCP guide.

What stays personal?

Each developer keeps these out of the repository:

• ~/.claude/settings.json, ~/.claude/CLAUDE.md and ~/.claude/rules/: preferences that apply to every project on that machine.
• .claude/settings.local.json: personal overrides for one project. The first time Claude Code writes it in a git repository, it adds **/.claude/settings.local.json to your global git excludes. If you create it by hand, add it to .gitignore yourself.
• CLAUDE.local.md at the project root: private instructions, such as your sandbox URLs. Add it to .gitignore. It exists only in the worktree where you created it.
• ~/.claude.json: Claude Code’s own file, holding your sign-in, local and user-scope MCP servers and trust decisions.
• Auto memory, in ~/.claude/projects/<project>/memory/.

When the same key appears in several places, Claude Code takes the highest of: managed settings, --settings on the command line, .claude/settings.local.json, .claude/settings.json, then ~/.claude/settings.json. The docs give an example of the escape hatch: if the team file sets "model": "claude-sonnet-5", putting "model": "claude-opus-5-5" in your local file changes only your sessions.

What can an admin enforce with managed settings?

Managed settings sit above everything: nothing in a developer’s files or in --settings overrides a managed key. They arrive three ways:

• Server-managed settings, fetched from the claude.ai admin console (included with Teams) or a self-hosted Claude apps gateway
• MDM or OS-level policies, and managed-settings.json files in a system directory
• An embedding host such as Claude Desktop

Developers run /status to see which managed source applies: the Setting sources line names it.

What admins usually set, from the docs:

• Login restrictions. forceLoginMethod and forceLoginOrgUUID require claude.ai logins to belong to your organization. Deploy these through device management, because server-managed settings only reach accounts already signed in to your organization. If you also use server-managed settings, set the keys in both places, since managed sources do not merge.
• Model limits. A managed model only sets the starting default. To restrict which models people can use, set availableModels and deniedModels.
• Permission rules. Allow rules normally merge across every scope. allowManagedPermissionRulesOnly stops developers adding their own.
• MCP servers. managed-mcp.json deploys a fixed set, managedMcpServers gives servers to everyone, and allowedMcpServers and deniedMcpServers restrict what people can add.
• Organization instructions. A managed CLAUDE.md at /Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux and WSL, or C:\Program Files\ClaudeCode\CLAUDE.md on Windows holds organization-wide instructions, such as security policies, that load alongside the project’s own.

A few security keys work the other way: Claude Code honors a stricter value from a lower scope even over a managed one, so disableClaudeAiConnectors: true applies from any scope. Of the managed sources, only server-managed settings reach cloud sessions; a managed-settings.json on a laptop does not.

Where should the team’s sessions keep what they learn?

People write CLAUDE.md and .claude/rules/ and review them in pull requests. Claude writes auto memory from your corrections, and the docs say it is machine-local: one directory per repository, shared across your worktrees but not across machines or cloud environments. What one developer’s Claude learns about a flaky test or a deploy step stays on that laptop. The Claude Code memory guide explains both systems.

Teams handle this in two ways. The first is to promote lessons into CLAUDE.md or a rules file by pull request. It is free and keeps the knowledge versioned with the code, which makes it the better choice when the knowledge is small and stable. The cost is length: Anthropic suggests keeping each CLAUDE.md under 200 lines, and everything in it loads every session.

The second is a shared store that every session reads and writes over MCP. If your team’s knowledge already lives in Notion or Confluence, their MCP servers bring it into Claude Code (see Notion MCP and Atlassian MCP).

Dexio is built for the case where the agents themselves write. It is a hosted wiki of linked markdown pages that Claude Code and a team’s other agents (Codex, Cursor and others) read, search and edit over MCP, and people see what their agents know as a page graph at app.dexio.wiki. Every change records the agent and person behind it. It is open source (AGPL-3.0) and free for one person. Team is $10 a member a month, and agents never count as members.

The server is https://app.dexio.wiki/mcp with an API key in a header. Each developer can add it at user scope, or the team can commit it to .mcp.json with each person’s key in their environment:

{
  "mcpServers": {
    "dexio": {
      "type": "http",
      "url": "https://app.dexio.wiki/mcp",
      "headers": { "Authorization": "Bearer ${DEXIO_API_KEY}" }
    }
  }
}

To get a key, ask Claude Code to follow https://dexio.wiki/agents.md; it starts a browser sign-in and adds the server itself.

What are Claude Code agent teams?

Agent teams are a different feature: several Claude Code sessions working on one task at once. One session is the lead and assigns work; teammates run in their own context windows, share a task list and message each other directly. The feature is experimental and off by default. Turn it on in the environment or in settings:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Teammates load the same project context as a normal session, including CLAUDE.md, MCP servers and skills, but not the lead’s conversation, so everything in the sections above also shapes an agent team.

Anthropic’s agent teams docs warn that teams use significantly more tokens, since each teammate is a separate instance. They also say sequential tasks and edits to the same file go better in one session or with subagents. Teammates run in-process by default; split panes need tmux or iTerm2 with the it2 CLI, set with teammateMode in ~/.claude/settings.json. We have not run agent teams for this guide. Claude Code best practices covers when to reach for them.

FAQ

Is Claude Code included in the Claude Team plan?

Yes. Anthropic’s authentication docs say Teams and Enterprise members get both Claude Code and Claude on the web. The Claude Team plan guide covers usage limits.

Can a team use API keys instead of seats?

Yes. Invite people in the Claude Console and give them the Claude Code or Developer role. Bedrock, Agent Platform and Foundry also work, with no browser login.

Should .claude/settings.local.json be committed?

No. It is for personal overrides and sits above the team’s .claude/settings.json. Claude Code keeps it out of git when it creates the file.

How do I check which settings my organization enforces?

Run /status in Claude Code. The Setting sources line names the managed source, and no file of yours overrides a key it sets.

Sources

• https://code.claude.com/docs/en/iam
• https://code.claude.com/docs/en/settings
• https://code.claude.com/docs/en/claude-directory
• https://code.claude.com/docs/en/memory
• https://code.claude.com/docs/en/mcp
• https://code.claude.com/docs/en/agent-teams
• https://github.com/atlassian/atlassian-mcp-server
• https://dexio.wiki/agents.md
• https://dexio.wiki/pricing/