[FEATURE] Merge managed settings sources (server side, mdm, file)
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_