[FEATURE] Merge managed settings sources (server side, mdm, file)

Open 💬 0 comments Opened Jul 7, 2026 by reecefenwick

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

We deploy Claude Code across a managed macOS fleet (Iru + claude.ai Enterprise), and our policy is naturally layered: a small org-wide baseline that must apply everywhere, plus host-level hardening (OS sandbox — network allowlist, filesystem.denyRead) pushed via MDM.

But managed sources don't merge — Claude Code uses only the first non-empty tier (server → plist → file) and ignores the rest. So it's all-or-nothing per tier:

  • The moment we put our baseline in the console, it silently shadows our entire MDM policy. Our sandbox config was read but never enforced; /status showed only (remote). We only got MDM to apply by emptying the

console — losing the universal layer.

  • That's now a silent footgun: with everything in MDM, adding any console setting later will invisibly disable our whole sandbox policy fleet-wide.

We can't express "a guaranteed baseline everywhere + additive hardening closer to the machine" without duplicating the full policy into one tier and keeping the others empty.

Proposed Solution

Merge the managed tiers in precedence order — server-managed → MDM (plist) → file — deep-merging each lower tier on top, under one invariant:

▎ A lower tier can only add or tighten restrictions, never loosen one set above it. The result is always at least as strict as any single tier.

Ideal flow: set the baseline once in the console (applies everywhere, un-weakenable), layer additive MDM hardening on top for Macs, optionally tighten further per-host via file. Machines without an MDM/file layer (Linux/Docker) just get the baseline. /status shows every contributing source and the provenance of each effective value.

Ideally opt-in (a merge-mode flag) so existing "first-wins" deployments are unaffected. Prior art already exists: managed-settings.d/ deep-merges file fragments, permissions.allow/deny merge across scopes, and
cross-source lock keys are honored from any source — this extends that composition across all three managed tiers.

Alternative Solutions

parentSettingsBehavior: "merge" — explored, doesn't apply. It only governs how settings supplied programmatically by an embedding host (Agent SDK / IDE extension) compose with the admin tier; it does nothing to merge the three admin managed sources (server → plist → file) with each other, which is what we need.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗