Configure Claude tools and environments for teams (e.g., Claude Code)

Key points

1. 1

   Settings live in a stack. ~/.claude/settings.json is personal and applies to every project on the machine; .claude/settings.json is shared with everyone in the repository (commit it); .claude/settings.local.json is a personal, gitignored override for one project; managed settings are deployed by the organization. Precedence, highest first: managed, command line (--settings, flags), project local, shared project, user.

2. 2

   Managed settings come from managed-settings.json in a system directory (/Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, C:\Program Files\ClaudeCode\ on Windows), from MDM or registry policy, or from server-managed settings in the claude.ai admin console. Nothing a developer sets overrides them, apart from a few security keys where a stricter lower-level value still counts. Verify with /status, which names the active setting sources.

3. 3

   Use managed settings for guarantees: permissions.deny rules such as Read(./.env), permissions.disableBypassPermissionsMode: "disable", allowManagedPermissionRulesOnly to ignore user and project rules, allowManagedHooksOnly, allowedMcpServers / deniedMcpServers, and an env block for provider and telemetry variables. Use the shared project file for team permissions, hooks, plugins and non-secret environment variables; use the user file for preferences such as theme, editor mode and default model.

4. 4

   List keys such as permissions.allow and permissions.deny merge across files rather than overriding. Rules are evaluated deny first, then ask, then allow; the first match wins and specificity does not matter, so an allow rule can never carve an exception out of a deny rule from any file.

5. 5

   permissions.defaultMode values auto and bypassPermissions do not take effect from project or local settings; set them in user or managed settings or pass --permission-mode for one session. A default mode only decides how a session starts; developers can still cycle modes with Shift+Tab.

6. 6

   Bash permission patterns match the literal command text, not the executable: Bash(curl *) as a deny does not match /usr/bin/curl or sh -c 'curl ...', and Bash(rm *) does not match find -delete. For a hard guarantee use the sandbox (filesystem and network isolation, with a managed network allow-list) or a PreToolUse hook that inspects the full command. Read and Edit deny rules also cover recognized file commands and redirections but not arbitrary subprocesses.

7. 7

   CLAUDE.md and permissions solve different problems: CLAUDE.md tells Claude how the project works (guidance), while permissions and hooks enforce limits regardless of what the model decides. Anything that must never happen belongs in a deny rule, a hook or the sandbox, not in an instruction.

8. 8

   Memory files load in order from broadest to most specific: managed CLAUDE.md (or the claudeMd key in managed settings), ~/.claude/CLAUDE.md, the project CLAUDE.md (or .claude/CLAUDE.md), then CLAUDE.local.md (gitignored). Files in parent directories load at launch; subdirectory files load on demand when Claude reads files there. .claude/rules/*.md holds topic files, optionally scoped with paths: frontmatter. /init generates a starting file; /memory and /context show what loaded.

9. 9

   MCP servers have three scopes: local (default, private, in ~/.claude.json), project (.mcp.json at the repository root, shared through git, requires a one-time approval in interactive sessions), and user (all projects, private). .mcp.json expands ${VAR} and ${VAR:-default} in command, args, env, url and headers, so secrets are supplied per machine and never committed. Per-project approval keys are enabledMcpjsonServers, disabledMcpjsonServers and enableAllProjectMcpServers; the organization-wide approved list is allowedMcpServers / deniedMcpServers in managed settings.

10. 10

    Anthropic recommends that one central team configures MCP servers and checks .mcp.json into the codebase, invests in CLAUDE.md documentation, provides a one-click install, starts new users with guided usage such as codebase Q&A and plan mode, and configures managed permissions that local configuration cannot overwrite.

11. 11

    Deployment options: Claude for Teams or Enterprise (recommended for most organizations; SSO, admin controls, server-managed settings), the Claude Console with API keys, or a cloud provider (Amazon Bedrock with CLAUDE_CODE_USE_BEDROCK=1, Google Vertex with CLAUDE_CODE_USE_VERTEX=1, Microsoft Foundry with CLAUDE_CODE_USE_FOUNDRY=1). Route through a corporate proxy with HTTPS_PROXY, or through an LLM gateway with ANTHROPIC_BASE_URL (and provider-specific base URL variables) when you need centralized auth, budgets or usage tracking. Pin provider model IDs with ANTHROPIC_DEFAULT_*_MODEL variables. /status shows the provider, base URL and proxy in use.

12. 12

    Cost tracking depends on the setup: Teams and Enterprise use the claude.ai analytics dashboard and spend report; Console customers use the Console usage page, workspace spend limits and the Claude Code Analytics API; Bedrock, Vertex and Foundry usage is billed to the cloud account and is not visible in Anthropic's dashboards. OpenTelemetry export works on every setup and is the only option that streams per-user token and cost metrics into your own stack in near real time.

13. 13

    OpenTelemetry: set CLAUDE_CODE_ENABLE_TELEMETRY=1 plus OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_EXPORTER_OTLP_PROTOCOL and OTEL_EXPORTER_OTLP_ENDPOINT. Metrics include claude_code.session.count, claude_code.cost.usage, claude_code.token.usage, claude_code.lines_of_code.count, claude_code.commit.count, claude_code.pull_request.count and claude_code.active_time.total, with attributes such as user.id, user.email, organization.id, session.id, model, query_source, mcp_server.name and skill.name. Add team or cost-center labels with OTEL_RESOURCE_ATTRIBUTES. Prompt text and tool content are excluded unless OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS or OTEL_LOG_TOOL_CONTENT are turned on. Deliver telemetry variables in the managed env block; a repository cannot turn telemetry on or redirect it from .claude/settings.json.

14. 14

    Traps the exam uses as distractors: storing secrets in a committed settings or .mcp.json file; putting team rules in ~/.claude.json (app state, not settings); committing settings.local.json; relying on CLAUDE.md wording for security; adding more Bash deny patterns instead of a hook or sandbox; expecting the Console dashboard to show Bedrock usage; and asking developers to self-report usage instead of exporting metrics.

Read the source

• Settings files and precedence
• Deploy managed settings
• Configure permissions
• How Claude remembers your project (CLAUDE.md)
• Connect to MCP servers
• Enterprise deployment overview
• Monitoring with OpenTelemetry
• Manage costs effectively