Treat the environment as layers, from what the whole organisation fixes to what one developer adds. Each layer has a place it lives and a person who owns it.

Anthropic's documentation describes how these combine: CLAUDE.md files are additive; skills and subagents override by name (managed over user over project for skills); MCP servers override by name (local over project over user); hooks merge so every registered hook fires; and managed settings apply above every other level (Source 1, Source 2). Design with that in mind: put non-negotiable rules at the managed layer, shared conventions in the project, and personal taste in your own files.

Chapter 10 showed a skill with a pre-approved tool and a ! command. The frontmatter has more levers (Source 3):

What that does and does not prove: the file is syntactically valid and uses only documented fields. It does not prove Claude selects it appropriately. Descriptions drive automatic loading, so write them with the words a request would contain; and keep the count of skills manageable — names always load, and when there are many, some lose their descriptions (Source 4).

A skill teaches Claude how to use something; an MCP server gives it a tool. The protocol is smaller than it looks. In the stdio transport the client launches your server as a subprocess; messages are single-line JSON-RPC 2.0 objects on standard input and output; and the server may log to standard error but must write nothing else to standard output (Source 5).

The spec requires the client to open with initialize (protocol version, capabilities, client info), the server to answer with its own, and the client to follow with a notifications/initialized notification before normal operation. Tools are discovered with tools/list and invoked with tools/call; a result carries content blocks and an isError flag. The spec also says tool execution errors belong in the result with isError: true so a model can self-correct, while unknown tools and malformed requests are JSON-RPC protocol errors (Source 5). Here is a complete server, about 40 lines, with no SDK, exposing one read-only tool backed by Chapter 11's feature_list.json:

You can test a server without any client by piping the protocol into it. This is the same exchange as the diagram, followed by a call to a tool that does not exist:

What it proves: the server follows the message shapes in the specification, including the -32602 "Unknown tool" error the spec itself shows as its example. What it does not prove: that a given Claude Code version can connect to it — I did not register it, because claude mcp add writes to your configuration. To register it for a project, the docs give this shape (stdio servers need no url):

A hook is the right place for anything that must happen without the model's cooperation. Beyond the two in Chapter 10, Anthropic's docs and best-practices page show these patterns (Source 8, Source 9):

• Prefer deterministic handlers (command, http) for enforcement. prompt and agent hooks ask another model to decide and are not deterministic; the agent type is experimental. Add onFailure: "block" when the action should also be stopped if the hook itself crashes or times out (Source 9).
• Hooks run with your privileges and outside the sandbox. Review hook scripts in anything you did not write.

One cost note that shapes the choice: connected MCP servers add their tool names and instructions to context even when idle (full schemas are deferred), so disable servers you are not using via /mcp (Source 10).

When the same setup is needed in several repositories, or you want versioned releases and updates, package it as a plugin: a directory of components that Claude Code installs and loads as one unit, with a manifest at .claude-plugin/plugin.json giving it a name (Source 11). A plugin can hold skills, agents, hooks, MCP servers and more. Here is bookshelf's, assembled from files already on this page and validated:

• Namespacing: plugin skills run as /plugin-name:skill-name, so they cannot collide with project skills (Source 11).
• Scopes: install at user scope (you, every project), project scope (everyone in the repo, through committed .claude/settings.json; each person still installs it) or local scope. Cloud sessions do not load local plugins.
• Cost: an enabled plugin is part of every session: the names and descriptions of its model-invocable skills and agents sit in context each turn, and its MCP servers and hooks run alongside. Check the footprint before installing; the /plugin interface shows a context-cost estimate for official-marketplace plugins.
• Trust: what a plugin runs, it runs as you. Plugins from any marketplace can run code with your privileges, so review them first.
• Not included on purpose: hooks. The plugin docs say plugins can carry hooks, but the path conventions for a plugin's hook scripts were not verified for this page, so the example omits them rather than guess.

Skills in repositories can also be run in CI: check out the repository, then pass the skill as the action's prompt (Chapter 11). Publishing and marketplaces are covered in Anthropic's plugin docs; hosting your own marketplace for a team is a marketplace.json catalogue you control.

Autonomy needs a boundary the model cannot argue with. Anthropic's docs offer three, and they stack (Source 12, Source 7, Source 13):

• Permission rules (deny → ask → allow, first match wins) are enforced by Claude Code, not the model, and are shareable in .claude/settings.json.
• The sandbox is an OS-enforced boundary around Bash (and PowerShell and Monitor) commands and their subprocesses: macOS uses Seatbelt, Linux and WSL2 use bubblewrap with a proxy relay; native Windows is not sandboxed. It is off by default (/sandbox or "sandbox": {"enabled": true}). Two gaps matter: reads are allowed across most of the machine by default, including credential files such as ~/.ssh and ~/.aws/credentials, until you restrict them; and failed commands can be retried unsandboxed unless allowUnsandboxedCommands is false.
• A container or VM puts the whole process behind one boundary. The dev-container page's own warning: with --dangerously-skip-permissions, a container does not stop a malicious project from exfiltrating anything accessible inside it, including Claude Code credentials in ~/.claude; use it only with trusted repositories and avoid mounting host secrets such as ~/.ssh.

Managed settings are what an organisation deploys to every machine; Claude Code applies them above every other level, so no user, project or local value overrides them, apart from a few security-sensitive exceptions where a stricter lower value still counts (Source 14).

File locations: /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux and WSL) and C:\Program Files\ClaudeCode\managed-settings.json (Windows). By default Claude Code uses one managed source and ignores the others; the page documents the order and an opt-in to combine them. Cloud sessions in Anthropic-hosted environments do not read a device's MDM profile or file, so policy for them must come from server-managed settings.

• permissions.disableBypassPermissionsMode: "disable" stops engineers using --dangerously-skip-permissions at all.
• forceLoginMethod and forceLoginOrgUUID restrict which accounts can sign in; allowedProviders lists which services a managed machine may reach Claude through (the Anthropic API, Amazon Bedrock, an LLM gateway…). With these set, an ANTHROPIC_API_KEY environment credential is blocked at startup, because organisation membership cannot be verified for it (Source 15).
• Policy a repository file can quietly change is not policy. The dev-container page warns that policy placed in a repository Dockerfile can be removed by anyone with write access; for policy engineers cannot bypass, use server-managed settings or MDM.
• Cost and observability: OpenTelemetry export gives per-user metrics on every setup; Teams and Enterprise have spend limits at organisation, group or member level; Console organisations use workspace limits (Source 16).
• Data handling: telemetry and error reporting can be disabled individually (DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING) or together with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC (Source 17) — covered in Chapter 13.
• Plugins at scale: managed settings can allowlist or block marketplaces, force-install plugins and turn off session-only loading.

Read the last column as the honest summary of this chapter. The environment is a set of small, inspectable files; the parts that could be exercised without a live Claude session were; the parts that depend on Claude Code's runtime behaviour are as documented, and the first thing to do when adopting any of it is to try it in a throwaway repository and watch it work.