Claude Code's Harness

Claude Code wraps Anthropic's models in a harness built around a small set of sharp tools and a deep stack of extension points — skills, subagents, hooks, plugins, layered memory, and MCP. This chapter walks that stack through the four-part lens from Chapter 1.

Source: Claude Code documentation (code.claude.com/docs). Features described are those documented as of mid-2026.

The built-in tools — a small, sharp menu

Claude Code gives the model a compact set of purpose-built tools rather than one all-purpose shell. For files there are Read, Edit, and Write; for discovery there are Glob (find files by pattern) and Grep (search contents by regular expression); for the outside world there are WebSearch and WebFetch; and for running anything else there is Bash. Orchestration tools round out the set — most importantly the Agent tool (historically called Task) for spawning subagents, and AskUserQuestion for pausing to clarify.

The narrowness is deliberate. Because reading, editing, and searching are distinct tools rather than shell invocations, each can be permissioned, sandboxed, and given clear feedback on its own terms — the exact benefit Chapter 1 attributed to a fine-grained tool interface. Every tool result flows back into the agentic loop, informing the model's next move.

Agent Skills — packaged know-how, loaded on demand

A Skill is a folder containing a SKILL.md file: YAML frontmatter plus Markdown instructions that teach Claude a reusable workflow or supply domain knowledge. The frontmatter carries a name and, most importantly, a description that tells Claude when the skill applies. Optional fields tune behavior — allowed-tools pre-approves specific tools while the skill is active, disable-model-invocation keeps it manual-only, and fields like model or context: fork can change how it runs.

Skills are the clearest embodiment of progressive disclosure. At session start Claude sees only each skill's short description — enough to know the capability exists — and loads the full instructions and any bundled reference files only when the skill is actually invoked. A dozen elaborate skills therefore cost almost nothing until one is needed. Skills live at several scopes with a clear precedence: personal skills in ~/.claude/skills/, project skills in .claude/skills/ checked into the repo, and skills shipped inside plugins.

Subagents and the Task tool — delegation with a clean desk

A subagent is a specialized assistant with its own context window, system prompt, tool access, and permissions. The main conversation delegates a task to it through the Agent tool, the subagent works independently, and only its final summary returns to the parent. The heavy intermediate work — dozens of file reads, long command output — never pollutes the main window.

Subagents are defined much like skills: a Markdown file with frontmatter carrying a required name and description, plus optional tools, a model choice (opus, sonnet, haiku, or inherit), and controls like permissionMode or maxTurns. Claude Code also ships built-in agents — a read-only Explore agent tuned for fast research, a Plan agent for exploration before editing, and a general-purpose agent for multi-step work. This is context management as architecture: bound a noisy job inside a child window and keep the parent focused.

Hooks — deterministic control you don't leave to the model

Where skills and subagents shape what the model chooses to do, hooks guarantee what always happens. A hook is a shell command wired to a lifecycle event and configured in settings.json. Documented events include SessionStart, UserPromptSubmit, PreToolUse and PostToolUse, Stop, and subagent lifecycle events, among others. A matcher can scope a hook to particular tools — for example, running a formatter after every Write or Edit.

Hooks can do more than run side effects. Through their exit codes and output they can block an action, inject extra context for the model to consider, or approve a step automatically — deterministic guardrails that do not depend on the model deciding to cooperate. Typical uses are auto-formatting after edits, blocking writes to protected files, and re-injecting important context after the conversation is compacted.

Plugins and marketplaces — bundling it all for sharing

A plugin packages these extension types into one shareable unit: skills, subagents, hooks, MCP server configurations, slash commands, and more, described by a plugin.json manifest. Installing a plugin lights up everything inside it at once, and skills within a plugin are namespaced (/plugin-name:skill-name) so they never collide.

Plugins are distributed through marketplaces — catalogs hosted on GitHub, another Git service, or a local path. An official Anthropic marketplace is available out of the box; teams can also run private marketplaces from a repository. In harness terms, plugins are how one team's carefully tuned tool interface, memory, and guardrails become another team's turnkey setup.

Permission modes — dialing safety against friction

Claude Code's safety layer is primarily policy: permission modes that set how often it pauses to ask. Documented modes include default (reads run freely, most actions ask), plan (read-only exploration), acceptEdits (file edits and common filesystem commands run without prompting), auto (broad autonomy with background safety checks), and bypassPermissions (no prompts — intended only for isolated containers or VMs).

On top of the mode, fine-grained rules in settings.json pre-approve or forbid specific actions using an allow/ask/deny list with a Tool(pattern) syntax — for instance allowing Bash(npm test) while denying Bash(rm *). The auto mode adds a background classifier that inspects actions before they run and blocks anything that escalates beyond the request or looks driven by hostile content, and certain sensitive paths are protected from auto-approval unless permissions are fully bypassed.

CLAUDE.md project memory — layered, persistent context

Persistent context in Claude Code lives in CLAUDE.md files loaded at the start of every session. They form a hierarchy that is concatenated rather than overridden: an organization-managed policy file, a user file at ~/.claude/CLAUDE.md for personal preferences across all projects, a project file checked into the repo for team conventions, and a local file for personal project-specific notes. Files are walked up from the working directory to the repository root, and — crucially — CLAUDE.md survives context compaction, so its guidance is re-injected after older conversation is summarized away.

An @path import syntax lets one memory file pull in others inline, keeping instructions modular. The documentation also describes an automatic memory that accumulates learnings over time as a complement to the hand-written CLAUDE.md. Together these give the model a stable base of project knowledge that does not have to be re-explained each session.

MCP — extending the tool interface itself

The Model Context Protocol (MCP) is an open standard that lets Claude Code connect to external servers exposing extra tools, read-only resources, and reusable prompts. Servers can be attached over several transports — a local stdio subprocess, or hosted HTTP, SSE, and WebSocket connections — and configured at local, project, or user scope (a project-scoped .mcp.json shares servers with teammates).

MCP is where the tool interface stops being fixed. A GitHub server, a browser-automation server, or an internal API server all appear to the model as new tools alongside the built-ins. To keep this from bloating the window, MCP tool definitions are loaded on demand rather than all upfront — the same progressive-disclosure discipline seen with skills, now applied to third-party tools.

The pattern underneath

Step back and a consistent philosophy emerges. Capabilities are disclosed progressively — skills and MCP tools announce themselves cheaply and load fully only when used. Configuration is layered across enterprise, user, project, and local scopes with clear precedence, so both central governance and personal tweaks coexist. Heavy work is isolated into subagents to protect the main context. And control is split between the model's judgment and deterministic hooks and permission rules that do not depend on it. Hold that pattern in mind: the next chapter shows a different set of answers to the very same four questions.