Part 1 of 5: The Claude Code Enterprise Stack

Three weeks after your team adopts Claude Code, two things happen simultaneously.

The first feels great: Anthropic reports a 67% increase in merged pull requests per engineer per day after adoption. Developers are shipping faster than ever. The Slack channel is buzzing. The velocity dashboard is beautiful.

The second feels wrong. A 2025 Index.dev study found that code review workload increased by 91% alongside those gains. Faster developers mean more code for reviewers to handle. And the same research found no measurable improvement in organization-wide DORA metrics — deployment frequency and lead time stayed flat.

Your velocity metrics are climbing. 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're stuck with a cruel choice: either enable chaos — developers bypass every guardrail — or create friction — policies so strict that Claude Code becomes an obstacle.

Neither works. There's a third path. And it starts with five tiers.

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. 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 design elegant: managed settings are the policy layer that can never be overridden. Not by CLI flags. Not by project settings. Not by anything. Everything below can be customized. Everything above stays locked.

Picture this. 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 an exception. With this hierarchy, they can:

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

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 structure. You need mechanics to deliver it. There are three ways to deploy managed settings, and the right one depends on what friction you're willing to accept — and for whom.

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. 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 actually matters.

Most organizations try to govern AI tools through checklists. Approval workflows. Culture lectures. Policies written in documents that live in Confluence and die on arrival.

None of that scales with Claude Code. And honestly? It never scaled with anything.

Claude Code demands 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. The security team stops spending cycles on exception requests because the system handles 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."

Governance without configuration is a speed bump. Configuration-based governance is infrastructure.

That line will matter more each time your team grows.

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.

What Comes Next

In Part 2, we'll take this hierarchy and turn it into actual CLAUDE.md files and settings.json configurations your team can use starting today. The exact structure. What goes where. Why.

But here's the decision you're making right now, whether you realize it or not: every day without a configuration hierarchy is a day your developers are building faster while your organization ships the same. The gap between individual velocity and organizational delivery widens. And that gap doesn't close by itself.

Configuration isn't overhead. It's the bridge. 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