Part 1 of 5: The Claude Code Enterprise Stack

Anthropic reports a 67% increase in merged pull requests per engineer per day after Claude Code adoption. Your team is shipping code faster than ever. Somewhere around week three, you notice something: according to a 2025 Index.dev study, code review workload increased by 91%. Faster developers mean more code for reviewers to handle. That same research found no measurable improvement in organization-wide DORA metrics—deployment frequency and lead time stayed flat. Your velocity metrics look impressive. Your delivery cycle hasn't budged.

This is the productivity paradox. And it's where most enterprise Claude Code deployments go sideways.

The problem isn't Claude Code. It's that you're trying to govern individual productivity without the infrastructure to turn it into organizational delivery. Without proper configuration, you face a cruel choice: either enable chaos (developers bypass every guard rail), or create friction (policies are so strict that Claude Code becomes an obstacle).

Neither works. There's a third path.

The Five-Tier Hierarchy: How Claude Code Decides What to Do

Think about how your DNS resolver works. You ask for a domain. It cascades up through multiple layers—checking your local cache first, then your network's resolver, then root nameservers—until it finds an answer. Each layer can override the previous one, but only up to a point.

Claude Code's configuration works the same way.

There are five tiers in the precedence hierarchy, and understanding them is the difference between a governance system that works and one that feels like busywork:

1. Managed settings (highest precedence, non-overridable)
2. Command line arguments (session-specific overrides)
3. Local project settings (personal project customization, git-ignored)
4. Shared project settings (team standards, version-controlled)
5. User settings (personal defaults, cross-project)

Here's what makes this elegant: managed settings are the policy layer that can never be overridden. Not by CLI flags. Not by project settings. Not by anything else. Everything below can be customized. Everything above it stays locked.

Let's say your security team decides that curl commands are too risky—they can be used to exfiltrate data. So they set Bash(curl *) as a deny rule in managed settings. An engineer on your backend team needs to test a one-off webhook. They want to make an exception. With this hierarchy, they can:

• Create a local project override in .claude/settings.local.json (git-ignored) that allows curl for their personal testing
• Claude Code still enforces the managed rule for anything pushed to version control
• Their testing works. Security policy still stands.

This is strong guardrails with weak handcuffs. The architecture says: "Here's what we can't compromise on. Within that boundary, do what you need to do."

According to official Claude Code documentation, "Managed settings have the highest precedence and cannot be overridden. This hierarchy ensures that organizational policies are always enforced while still allowing teams and individuals to customize their experience."

Three Deployment Mechanisms: Which Fits Your Team?

The hierarchy is just structure. You need mechanics to actually deliver it. There are three ways to deploy managed settings. Each has trade-offs.

Server-Managed Settings (Simplest)

Policies are pushed from Anthropic's servers to Claude Code clients. You configure them in the Claude.ai admin console. Clients check for updates at startup and hourly after.

Pros: No MDM infrastructure needed. Real-time policy updates. Developer-friendly UI for changes.

Cons: Network-dependent. Requires Team v2.1.38+ or Enterprise v2.1.30+.

Best for: SMEs without existing device management infrastructure who want fast rollout.

MDM/OS-Level Policies (Tamper-Proof)

Policies live at the OS level via Jamf (macOS), Intune (Windows), or Group Policy. Enforced at the operating system layer—users can't modify them without admin access.

Pros: Tamper-resistant. Integrates with existing IT infrastructure. Mandatory for regulated industries.

Cons: Slower policy propagation. Requires MDM enrollment. More IT overhead to maintain.

Best for: Organizations with existing MDM infrastructure or regulatory compliance requirements.

File-Based Settings (Simplest to Implement)

JSON files deployed to system directories:

• macOS: /Library/Application Support/ClaudeCode/
• Linux: /etc/claude-code/
• Windows: C:\ProgramData\ClaudeCode\

Supports drop-in managed-settings.d/ directories where multiple JSON files merge automatically (sorted alphabetically).

Pros: Simplest to implement. No network dependency. Modular—different teams can drop in their own policy files without conflicts.

Cons: Less secure—users with admin access can modify directly. No real-time updates.

Best for: Small teams, internal tools, development environments.

Mark Bennett, CTO at New Idea Engineering, offers a principle that applies here: "Managers remove blockages and busy-work from their underlings. MINIMAL BUSYWORK for engineers." Governance should enable, not block. Your choice of deployment mechanism should reflect that. Server-managed is frictionless for engineers. File-based is frictionless for implementation. MDM is frictionless for compliance. Pick the one that removes friction for your specific context.

Beyond Tools: Why Configuration IS Your Governance Model

Here's the shift in thinking that matters.

Most organizations try to govern AI tools through checklists, approval workflows, or culture. Policies written in documents. Reviews after the fact. Culture lectures.

None of that scales with Claude Code.

Claude Code requires technical governance baked into configuration. When you set a deny rule for .env files, that's not a suggestion—it's a technical barrier. When you deploy hooks that check for test coverage before allowing commits, that's not a guideline—it's an automated gate. When you standardize MCP server access through managed settings, that's not a training item—it's architecture.

The real insight: Configuration is code. Version-controlled. Reviewable. Testable. Hierarchical.

When configuration is right, governance becomes nearly invisible. Developers don't feel blocked because rules are context-aware (they can override at the project level, just not enterprise policy). Security team doesn't spend cycles on exceptions because policy is flexible enough to handle nuance. Leadership gets compliance through technical enforcement, not checklists and prayers.

Official documentation states: "Server-managed settings and endpoint-managed settings both occupy the highest tier in the Claude Code settings hierarchy. No other settings level can override them, including command line arguments. Within the managed tier, the first source that delivers a non-empty configuration wins."

This is the architectural insight: Governance without configuration is a speed bump. Configuration-based governance is infrastructure.

The Decision Matrix

Before you implement, map your context to the right approach:

The configuration hierarchy enables all of this. You're not picking a model. You're picking an approach to governance that scales with your team.

In Part 2, we'll take this hierarchy and turn it into actual CLAUDE.md files and settings.json configurations that your team can use starting today. We'll show the exact structure, what goes where, and why.

But first: understand that configuration is your lever. It's not overhead. It's the bridge between individual developer velocity and organizational delivery. Get it right, and everything else follows.

Series Navigation

• Post 1: Why Configuration Matters More Than Models (you are here)
• Post 2: Building Your First CLAUDE.md
• Post 3: Hooks: Deterministic Policy Enforcement
• Post 4: Skills, Agents, and Private Marketplaces
• Post 5: Measuring ROI and Scaling Beyond Day One