Claude Code admin controls: a practical guide for IT and DevOps

Start with the control boundary

Managed settings, server-managed settings, and project settings influence Claude Code behavior. They can make the supported application prefer or require an organization policy. They cannot prevent someone with sufficient control of a machine from using a modified or different client, nor can they revoke authority already granted by an API key, shell account, or downstream service.

That distinction changes the design. Use client settings for productive defaults and auditable guardrails. Use device management, least-privilege cloud credentials, repository controls, network egress policy, and the downstream system’s own authorization for enforcement.

Know the setting scopes

Claude Code documents five precedence layers: managed settings, command-line arguments, local project settings, shared project settings, and user settings. Higher precedence changes the supported client’s effective value; arrays and individual keys can have their own merge behavior. Check Settings for the release you deploy rather than assuming every key behaves like a scalar override.

Use shared project settings for repository conventions. Use local settings for a developer’s machine-specific needs. Use managed settings for organization policy; server delivery is one way to distribute them. Do not put a secret in CLAUDE.md or treat it as a policy engine: it is agent guidance, and must be readable to do its job.

Deliver and verify the policy

Managed settings can arrive through the admin console, OS/device policy, or a system file. File locations include:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux and WSL: /etc/claude-code/managed-settings.json
• Windows: C:\\Program Files\\ClaudeCode\\managed-settings.json

Run /status to see which source loaded, and claude doctor to inspect rejected configuration. By default, multiple managed sources do not all merge: the highest-ranked source with policy keys generally wins, with documented exceptions. Review managedSourcesBehavior before deliberately composing sources.

Server delivery also depends on authentication and provider selection. For example, a third-party model provider or custom API base URL can skip the Anthropic server-managed fetch. Use the documented delivery path for the environment rather than assuming a console setting reached every device.

Permission policy: narrow and testable

The permissions reference distinguishes allow, ask, and deny rules; deny takes precedence over ask, then allow. Start with the smallest allow rules that let a development workflow work. Add explicit deny rules for actions your organization will not permit. A permission prompt is a decision point, not proof that the command, credential, or remote API is safe.

Test each rule against realistic work: read a repository file, run the approved formatter, attempt an excluded command, call an approved tool with bad input, and verify the downstream service rejects unauthorized access. Lower scopes may add stricter exceptions; do not assume a permissive user rule overrules a managed restriction.

A small managed-policy example is:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)"],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

This disables bypass mode and makes managed settings the only settings source for permission rules. It is not a complete security policy or a general block on network access. Test normal work before enforcing it broadly. Avoid a blanket allowance for every npm run or make command: scripts can execute more than their names suggest.

MCP needs an endpoint review

Managed MCP lets administrators define MCP servers and can filter configured servers. allowManagedMcpServersOnly locks the managed allowlist; it does not make project MCP configuration vanish or turn a friendly serverName into a security identity. Review a server by its URL or command, its credentials, requested tools, data path, and the service permission it receives.

For every MCP integration, write down: which client starts it, where its token comes from, what API operations it can perform, and what happens when it is unavailable. Then test a denied server and an allowed server with a credential that lacks the target action.

There are two different designs. Deploy managed-mcp.json for a fixed server set, with documented in-process exceptions. Use allowedMcpServers plus allowManagedMcpServersOnly for an authoritative catalog that filters user-configured servers. That allowlist does not install the servers.

For a remote server, match its approved serverUrl; for a local server, match its exact serverCommand and arguments. A user-selected name is not proof of endpoint identity. Keep credentials out of world-readable managed configuration and test the token's actual service permissions.

Sandboxing reduces some Bash risk, not all risk

Sandboxing applies native isolation to supported Bash activity. It has platform limits: macOS, Linux, and WSL2 are supported, while native Windows is not. Unsandboxed retries and explicitly excluded commands need separate review. Treat those cases as a reason to review the command and host controls, not as proof that the sandbox covers them.

Use the sandbox for a specific threat model: define writable paths, required network destinations, and commands that must remain outside the permitted workflow. Verify the denied filesystem and network cases. A sandbox cannot make an already-authorized cloud credential harmless.

If the policy requires sandboxed execution, review sandbox.allowUnsandboxedCommands: false and every excludedCommands entry together. The former disables the normal retry escape, but does not erase exclusions. With autoAllowBashIfSandboxed enabled, the sandbox can replace whole-tool Bash prompts; content-specific ask rules and explicit denials still matter.

Hooks, instructions, and telemetry

Use PreToolUse hooks for an additional tool decision. A blocking hook can stop a call; a hook's allow result does not override a matching deny or ask rule. Review the hook implementation itself before deploying it.

A ConfigChange hook can record settings-file changes, but server-managed policy updates and MDM changes do not trigger that file-change event. Do not describe that hook as a complete organization audit log. Decide which events you need, where they are stored, and whether they could contain sensitive data.

Keep CLAUDE.md for readable working guidance. “Never disclose credentials” is useful instruction, but it does not remove credentials from a process or revoke a token.

A rollout checklist for IT and DevOps

1. Define the supported client, managed-device boundary, repositories, and external systems in scope.
2. Deploy a minimal managed policy to a pilot group; inspect the effective sources and permissions in Claude Code.
3. Test normal development work, denied commands, project-level stricter exceptions, managed MCP, and sandbox fallback behavior.
4. Test the credentials and downstream APIs separately. Rotate or revoke a test credential to confirm that authority is actually enforced outside the client.
5. Document an exception path, update cadence, owner, and incident response route.

Let Claude Code inspect an eesel teammate within those controls

The same administration questions arise when Claude Code uses eesel CLI. A support administrator can ask it to inspect connected knowledge and standing instructions, then propose an update to the teammate that already works in the eesel dashboard. A person or an approved script can run those commands too; all return JSON.

Keep three decisions separate: may Claude Code run the local command, may this eesel identity access the workspace, and may the teammate act in the connected helpdesk? Approving Bash once does not grant every downstream action.

For an owner-approved inspection, select the existing teammate explicitly:

npx @eesel/cli whoami
npx @eesel/cli integrations --agent "support-policy"
npx @eesel/cli instructions --agent "support-policy"

Node.js 18.17+ is required. Confirm the workspace and teammate name, and review whether the returned policy may enter the coding agent's model context. Do not paste credentials or customer exports into the prompt.

Then give Claude Code a concrete comparison: “Our approved policy sends account-deletion requests to the Privacy team after identity verification. Compare that requirement with the returned instructions. Identify missing wording and propose a minimal diff; do not apply it.” The expected result is a source-backed edit and test cases for verified identity, unverified identity, and a request outside the policy—not a new permission grant.

The owner reviews the diff, checks instructions --help, and previews a supported write with --dry-run before applying it. Confirm the saved instructions through the CLI or dashboard. After reviewing action permissions, run approved synthetic cases in fresh conversations and inspect activity. Chat is real, billed work, and approvals lists only held actions. Finally test the helpdesk path itself: a good CLI response is not proof of routing or access control.

This gives admins a practical way to review support configuration from their coding workflow while keeping each system's authorization explicit. Try eesel