Claude Code becomes dramatically more valuable when a team invests in shared infrastructure. This module covers the conventions, security practices, and cost management that make Claude Code work at team scale.

Shared CLAUDE.md

The project-level CLAUDE.md (in your repo root) is the team's shared brain. It should contain conventions everyone follows:

• Build, test, and lint commands (exact syntax)
• Code style rules and architectural patterns
• Libraries to use (and explicitly not use)
• File structure conventions
• Common pitfalls specific to your codebase

Personal preferences go in .claude/CLAUDE.local.md — your preferred editor, personal aliases, workflow quirks. This file is gitignored by default and doesn't clutter the team's shared context.

The Team Compounding Habit

The compounding engineering habit from the Context module scales powerfully across a team:

1. Developer makes a PR with Claude's help
2. Reviewer spots a convention violation (e.g., Claude used the wrong test helper)
3. Reviewer adds to CLAUDE.md: the rule that prevents this next time
4. Every future Claude session follows the updated rule

With GitHub integration, this can be even more streamlined: a reviewer comments @claude add this to CLAUDE.md so you don't do it again — and Claude creates a PR updating the rules file.

Over weeks, the team's CLAUDE.md converges on a precise, tested set of conventions. New team members (and their Claude sessions) start with all the accumulated knowledge.

Git Worktrees for Parallel Team Work

When multiple developers are using Claude Code simultaneously, branch collisions can become a problem. Git worktrees solve this:

# Each developer (or each Claude session) gets its own worktree
git worktree add ../project-feature-auth feature/auth
git worktree add ../project-feature-billing feature/billing
git worktree add ../project-fix-login fix/login-bug

Each worktree is a separate directory with its own checkout. Claude sessions in different worktrees can't conflict — they're editing physically separate file trees.

For cleanup:

git worktree remove ../project-feature-auth

Distributing Commands and Skills

Teams can standardise workflows by sharing commands, skills, and agents through several mechanisms:

For team standardisation, the project .claude/ directory is usually the right choice — it travels with the code and is version-controlled.

Managed MCP Configuration

For teams that need control over which MCP servers developers can use, Claude Code supports managed configuration:

Allowlists and Denylists

Administrators can control MCP access at the organisation level:

{
  "allowedMcpServers": [
    { "serverName": "github" },
    { "serverCommand": ["npx", "-y", "@playwright/mcp@latest"] }
  ],
  "deniedMcpServers": [
    { "serverName": "unrestricted-web-fetcher" }
  ]
}

Deny rules take precedence over allow rules. This ensures that even if a developer configures a risky MCP locally, the team policy blocks it.

Shared MCP Config

Put team MCP configurations in .mcp.json at the project root. This gets committed to git, so everyone gets the same tool set when they clone the repo:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-github"]
    }
  }
}

Security Posture

Claude Code introduces a new category of security considerations. The main areas to think about:

Prompt Injection via MCPs

MCP servers that fetch content from untrusted sources (web pages, emails, user input, Slack messages) can expose Claude to prompt injection — where the fetched content contains instructions that manipulate Claude's behaviour.

Mitigation: use read-only MCP configurations where possible, and be cautious with MCPs that fetch untrusted external content.

Credential Management

• API keys and tokens for MCP servers should use environment variables, never hardcoded values
• Sensitive config should not be committed to version control
• Use .env files or your system's secret management

Tool Permissions

Configure permissions thoughtfully rather than blanket-skipping them:

{
  "permissions": {
    "allow": [
      "Bash(bun run test:*)",
      "Bash(bun run lint:*)",
      "Bash(git:*)",
      "Read",
      "Glob",
      "Grep"
    ]
  }
}

This pre-approves safe operations (tests, linting, git, reading files) while keeping permission prompts for potentially destructive actions (installing packages, modifying system files, running arbitrary scripts).

Security Hooks

Use PreToolUse hooks to enforce security rules automatically:

{
  "PreToolUse": [{
    "matcher": "Edit",
    "hooks": [{
      "type": "command",
      "command": "echo $FILE_PATH | grep -q '.env\\|credentials\\|secrets' && echo 'BLOCKED' && exit 2 || exit 0"
    }]
  }]
}

This prevents Claude from editing files that contain secrets — regardless of what it's asked to do.

Cost Management for Teams

At team scale, Claude Code costs need monitoring and governance:

Budget Limits

For API key users, set per-session limits:

claude --max-budget-usd 10

Model Routing as Cost Control

Establish team conventions around model usage:

• Default to Sonnet for all standard development work
• Use Haiku for mechanical agent tasks (scouts, format checks, simple reviews)
• Reserve Opus for tasks requiring deep reasoning (security audits, architectural decisions)
• Review Opus usage — if a task can be done equally well with Sonnet, it should be

Session Hygiene

The biggest cost driver is unnecessarily long sessions. Team conventions that help:

• /clear when starting a new task (don't carry old context forward)
• /compact when a session has useful context but accumulated noise
• Commit and start fresh rather than continuing a 50+ message session
• Use @filename references instead of letting Claude search (cheaper and faster)

Key Takeaway

Claude Code at team scale is about shared infrastructure: a well-maintained CLAUDE.md, standardised commands, managed MCP config, thoughtful security, and cost-aware conventions. The team's Claude Code setup is itself a codebase — one that compounds in value over time as you invest in it.