[FEATURE] Admin API to read/write server-managed Claude Code settings (policy-as-code / CI-CD)

What

Server-managed Claude Code settings (the managed policy configured at claude.ai/admin-settings/claude-code) can currently only be edited by hand in the admin console UI. There is no programmatic way to read or write that policy.

The existing Admin API (sk-ant-admin… / org:admin) covers members, workspaces, API keys, invites, and usage — but not the managed-settings policy. The Compliance API can read effective settings, but it's Enterprise-only and read-only.

Why / use case

Organizations managing Claude Code at scale want to treat the managed-settings policy as policy-as-code:

• Source of truth in git — allow/deny lists, hooks, and locks live in a repo, reviewed via pull request.
• CI/CD push — a pipeline validates the policy and applies it on merge, so every change is reviewed, versioned, and auditable, with a clear rollback (revert the commit, re-apply).
• Scale — production deny lists run to hundreds of entries; hand-editing them in a web textarea is error-prone and unreviewable as a diff.

Today the only path is a human pasting JSON into the console on every change. That doesn't fit a CI/CD workflow, has no diff/review/rollback story, and is easy to get wrong.

Proposed solution

Extend the Admin API with endpoints for the Claude Code managed-settings policy, for example:

• GET .../organizations/claude_code/managed_settings — return the current policy plus a version identifier / ETag.
• PUT .../organizations/claude_code/managed_settings — replace the policy and return the new version. Optionally honor an If-Match version to prevent lost updates.
• (optional) POST .../managed_settings:validate — dry-run validation without applying, for CI pre-merge checks.
• (optional) per-workspace scoping to match the existing console structure.

Given this is a security-sensitive surface, reasonable guardrails:

• Writes restricted to Owner / Primary Owner (mirroring the console), or a dedicated scope.
• Every write recorded in the audit log / Activity Feed with actor and diff.
• Server-side schema validation that rejects unknown keys.

A read-only endpoint alone would already be valuable — it enables drift detection (comparing the live policy against the repo source) even without write access.

Alternatives considered

• File-based managed-settings.json + managed-settings.d/ — good for policy-as-code on the endpoint/MDM channel, but it does not reach the server-managed channel that governs Desktop, web, mobile, and cloud sessions. Those surfaces can only be governed from the console.
• Compliance API — reads effective settings, but Enterprise-only and read-only; no write path.

Related issues

• #44640 — server-managed settings not syncing (consumer side of the same policy)
• #43355 — forceRemoteSettingsRefresh fetch/refresh behavior
• #47741 — organization-managed CLAUDE.md (adjacent enterprise-policy request)