--- title: "What Is Claude Code? The Terminal Agent and Its Extension Model" excerpt: "Claude Code is Anthropic's terminal-based coding agent: it reads your codebase, edits files, runs commands, and connects to external tools over MCP. This hub explains how teams actually run it, how its five extension layers (skills, hooks, subagents, MCP servers, plugins) fit together, and the one thing it cannot see on its own: a real browser." metaDescription: "What is Claude Code? Anthropic's terminal coding agent explained: how it works, its five extension layers, and the verification gap teams need to close." publishedAt: 2026-08-03 author: Will categories: - Guides - Engineering tags: - claude-code - what-is-claude-code - claude-code-skills - claude-code-hooks - claude-code-subagents - mcp - claude-code-plugins - terminal-coding-agent - anthropic metaTitle: "What Is Claude Code? The Terminal Agent Explained" featuredImage: ./cover.png featuredImageAlt: "Shiplight blog cover, light gradient, indigo accents, diagram of the Claude Code agent core surrounded by five extension layers labeled skills, hooks, subagents, MCP servers, and plugins" --- Claude Code is Anthropic's terminal-based coding agent: a CLI program that reads your codebase, edits files, runs shell commands, and connects to outside tools through the Model Context Protocol. You describe a task in plain language, and it plans the work, makes the changes across multiple files, runs your tests, and commits the result. If you are evaluating it, the single most useful mental model is this: Claude Code is a small agent loop wrapped in a large extension surface. The core loop is simple. The model proposes an action (read a file, run a command, edit a line), the harness executes it, and the output feeds the next decision. Everything else that makes Claude Code useful in a real engineering organization lives in the layers you attach to that loop. There are five of those layers: skills, hooks, subagents, MCP servers, and plugins. Each answers a different question. Skills answer "how do we do this task here." Hooks answer "what must happen every single time, no matter what the model decides." Subagents answer "how do we keep side work out of the main context." MCP servers answer "what can the agent reach beyond the repo." Plugins answer "how do we ship all of the above to forty engineers without a wiki page." This page is the hub for our Claude Code cluster. It covers what the tool is, how teams run it in practice, what each extension layer does (with a deep page on each), where the agent is blind, and when a different tool is the better call. We write from daily use: our own repo carries committed skills, hooks, and agent definitions, and most of what follows comes from maintaining them. ## What Claude Code Actually Is Anthropic's docs describe Claude Code as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools." Strip the category language and it is a REPL for delegated work. Install is one line (`curl -fsSL https://claude.ai/install.sh | bash`, or `brew install --cask claude-code`), then `claude` in any project directory starts a session. Three properties define it in practice: **It operates on the real filesystem and shell.** Claude Code does not work on a copy of your code in a chat window. It greps, reads, edits, and runs `pnpm test` in your actual working tree, which means its feedback loops are your feedback loops: compilers, test runners, linters. **It is composable.** It follows the Unix philosophy: `tail -200 app.log | claude -p "find the anomaly"` works, and so does running it headless in CI. The same engine now also runs in VS Code, JetBrains, a desktop app, and the browser, but the terminal remains the reference surface and the one every extension mechanism targets. **It reads project memory.** A `CLAUDE.md` file at the repo root loads at the start of every session: conventions, architecture decisions, commands, guardrails. It also builds auto memory as it works, saving learnings like build commands across sessions. This file is where teams encode "how we work here," and it is the cheapest extension point of all, plain instructions. ## How Teams Actually Run It The published demos show one developer chatting with one agent. Teams that ship with Claude Code daily converge on a different shape. **Plan first, then execute.** [Plan mode](/blog/claude-code-plan-mode) puts the session in a read-only research state: Claude explores the codebase and produces a plan you approve before any file changes. For anything beyond a one-line fix, plan mode is the difference between reviewing a diff you expected and reverting one you did not. Our deep page covers when to force it and when it slows you down. **Encode the workflow, not just the prompt.** Mature setups check `.claude/` into the repo: a `CLAUDE.md`, project skills, hooks in `settings.json`, agent definitions. A new engineer clones the repo and inherits the whole operating setup. The prompt becomes the smallest part of the system. **Scale out, carefully.** For work that splits into independent tracks, [agent teams](/blog/claude-code-agent-teams) let multiple Claude Code sessions communicate, with a lead agent assigning subtasks and merging results. It is genuinely useful for wide, parallelizable work (migrations, multi-service changes) and genuinely wasteful for anything a single session could finish in a handful of tool calls. The deep page covers the coordination costs the demos skip. **Automate the recurring runs.** Headless mode (`claude -p`) plus GitHub Actions handles PR review and issue triage; scheduled routines handle overnight jobs. At that point Claude Code stops being an assistant and becomes infrastructure, which is exactly when the deterministic layers below start to matter more than the prompts. ## The Extension Model: Five Layers The five layers differ on one axis that matters more than any feature list: whether the behavior is guaranteed or model-discretionary. Skills and subagents shape what the model does; hooks constrain it; MCP extends its reach; plugins package the rest. | Layer | What it is | When to reach for it | Deterministic? | |---|---|---|---| | Skills | Markdown instructions (`SKILL.md`) loaded on demand | A procedure you keep re-explaining in chat | No, model follows instructions; `/name` forces invocation | | Hooks | Shell commands bound to lifecycle events | A rule that must run every time (format, lint, block) | Yes, fires on the event regardless of the model | | Subagents | Scoped workers with their own context window | Side tasks that would flood the main context | No, delegation is a model decision you can prompt | | MCP servers | Protocol connections to external tools and data | Anything outside the repo: issue trackers, databases, browsers | No, the model chooses when to call; the server's behavior is fixed | | Plugins | A distributable package of the above | Sharing one setup across repos and teammates | N/A, packaging layer | ### 1. Skills A skill is a folder containing a `SKILL.md` file: instructions, optionally with supporting files, that Claude loads only when the task calls for it. That progressive disclosure is the point: unlike `CLAUDE.md`, which occupies context in every session, a skill's body costs nothing until it is used. Claude invokes skills on its own when the description matches the task, or you invoke one directly with `/skill-name` (custom slash commands have been merged into skills, so both mechanisms are now one). The practical trigger for writing one: you have pasted the same checklist into chat three times, or a section of `CLAUDE.md` has grown into a procedure. Our [guide to Claude Code skills](/blog/claude-code-skills) covers the format, the frontmatter, and the failure modes; [how to create a skill](/blog/create-claude-code-skill) walks one from scratch. ### 2. Hooks Hooks are shell commands (or HTTP calls, or prompts) that Claude Code runs at fixed lifecycle events: `PreToolUse` before a tool call, `PostToolUse` after one, `UserPromptSubmit`, `SessionStart`, `Stop`, and a few dozen others. They live in `settings.json` at user, project, or local scope. What separates hooks from every other layer is that they are not suggestions. A `PreToolUse` hook that exits with code 2 blocks the tool call; the model cannot argue with it. This is how you make "run prettier after every edit" or "never touch `.env`" a guarantee instead of a request. Our [Claude Code hooks guide](/blog/claude-code-hooks) covers the event list, the JSON output contract, and the hooks worth writing first. ### 3. Subagents A subagent is a scoped worker defined as a Markdown file with YAML frontmatter (`.claude/agents/` for a project, `~/.claude/agents/` for your machine): its own system prompt, its own tool allowlist, optionally a cheaper model, and critically its own context window. When the main session delegates, the subagent burns its context on the noisy work (searching, reading, log-diving) and returns only a summary. Claude Code ships built-ins (Explore, Plan, general-purpose) and delegates to them automatically; custom subagents let you constrain and reuse that pattern. Subagents work inside one session, which distinguishes them from agent teams above. Our [Claude Code subagents guide](/blog/claude-code-subagents) covers definitions, delegation behavior, and when subagents cost more than they save; [the subagent concept page](/blog/subagent) covers the general idea. ### 4. MCP Servers The Model Context Protocol is the open standard for connecting agents to external systems, and MCP servers are how Claude Code reaches anything outside the repo: Jira tickets, a Postgres database, design files, a live browser. `claude mcp add --transport http ` connects a remote server; local servers run over stdio; project-scoped servers live in a checked-in `.mcp.json` so the whole team gets them. Each server exposes tools the model can choose to call, which makes MCP the layer that most changes what Claude Code can do rather than how it does it. Start with [our MCP for Claude explainer](/blog/claude-mcp), see [which servers are worth installing](/blog/best-mcp-servers-claude-code), and see [what MCP is](/blog/what-is-mcp) for the protocol itself. ### 5. Plugins A plugin is the distribution layer: one directory with a `.claude-plugin/plugin.json` manifest that bundles skills, agents, hooks, and MCP server configs together, installable through marketplaces (Anthropic runs an official one and a community one) with the `/plugin` command. Nothing in a plugin is new capability; the value is that "our team's Claude Code setup" becomes a versioned artifact instead of a copy-pasted folder. Plugin skills are namespaced (`/my-plugin:deploy`), which prevents collisions across sources. The honest guidance from the docs matches our experience: start with standalone `.claude/` configuration, and convert to a plugin only when sharing across repos or teammates is the actual problem. Our [Claude Code plugins guide](/blog/claude-code-plugins) covers the anatomy and the promotion decision. ## The Verification Gap: What Claude Code Cannot See Every layer above extends what Claude Code can do. None of them changes what it can see, and out of the box it cannot see a browser. Claude Code verifies through the terminal: exit codes, test output, compiler errors. That covers logic well. It does not cover the thing most product code ultimately produces, a rendered UI. When Claude Code writes a checkout form, it can confirm the code compiles and the unit tests pass. It cannot confirm the submit button is visible, the layout survived, or the flow completes in an actual browser. The agent reports "done" based on the evidence it has, and its evidence stops at stdout. In practice this is where agent-written UI changes fail: not in the logic, but in the parts nobody executed. Closing that gap means giving the agent eyes and hands in a real browser, which is an MCP problem, layer four above. This is what we build: Shiplight installs into Claude Code as a browser MCP server plus skills (one-line install, no account for local use), so the agent can drive a real browser, watch its own change render, and turn that check into an intent-based YAML test that lives in your repo and transpiles to standard Playwright. Whether you use Shiplight or assemble the pieces yourself, the requirement is the same: an agent that cannot observe its output cannot verify it. Our [guide to testing with Claude Code](/blog/claude-code-testing) covers the full picture, from terminal-side checks to browser verification. ## When Claude Code Is Not the Right Pick Honest scope, from daily use: **You want an editor, not a delegate.** Claude Code's home is the terminal and its unit of work is the task. If your working style is inline completions and small, continuous edits with your cursor in the file, an IDE-native agent fits better. The trade-offs run deeper than surface preference; our [Claude Code vs Cursor comparison](/blog/claude-code-vs-cursor) works through them. **Your stack and billing live elsewhere.** Claude Code requires a Claude subscription or API billing. If your organization is committed to another provider's models and pricing, the equivalent terminal agents there are credible, and the extension models differ in ways that matter. See [Codex vs Claude Code](/blog/codex-vs-claude-code) for a working comparison, and [OpenCode vs Claude Code](/blog/opencode-vs-claude-code) if an open-source harness is a requirement. **The task is small and the context is not.** For a one-file fix you could type in ninety seconds, an agent loop that explores, plans, and verifies is overhead. Claude Code earns its cost on multi-file, multi-step work. **You need guarantees the model layer cannot give.** Skills and prompts are steering, not enforcement. If a behavior must hold one hundred percent of the time, it belongs in a hook, a CI gate, or a test, and if your team is not prepared to build those deterministic rails, the agent's variance will find you. ## Frequently Asked Questions ### What is Claude Code? Claude Code is Anthropic's terminal-based coding agent: it reads your codebase, edits files, runs shell commands, and connects to external tools through MCP. You describe a task, it plans and executes the work, and it verifies what it can through your own test and build commands. ### Is Claude Code free? No. Claude Code requires a paid Claude subscription or Anthropic API billing through the Console; the terminal CLI and VS Code extension also support some third-party model providers. The software itself installs free, but every session consumes model usage. ### What are the five extension layers of Claude Code? Skills, hooks, subagents, MCP servers, and plugins. Skills package repeatable instructions, hooks run deterministic commands at lifecycle events, subagents isolate side work in separate context windows, MCP servers connect external tools and data, and plugins bundle all of these for distribution. ### What is the difference between skills and hooks in Claude Code? Skills are instructions the model follows; hooks are commands the harness executes. A skill can be ignored or misapplied because the model interprets it, while a hook fires on its event every time and can block an action outright. Use skills for judgment, hooks for guarantees. ### Does Claude Code only run in the terminal? No. The same engine runs in VS Code and JetBrains extensions, a desktop app, the web at claude.ai/code, and the Claude mobile apps, and sessions can move between surfaces. The terminal remains the full-featured reference surface, and shared configuration like CLAUDE.md and MCP servers works across all of them. ### Can Claude Code test its own code? Partially. It runs unit tests, linters, and builds in the terminal and reacts to their output, but it has no browser by default, so it cannot see whether a UI change actually renders or a flow completes. Closing that requires a browser MCP server; see our Claude Code testing guide. ## Related Reading - [Claude Code testing guide](/blog/claude-code-testing): how to close the verification gap this page describes. - [Claude Code skills](/blog/claude-code-skills): the deep page on the first and most-used extension layer. - [Claude Code hooks](/blog/claude-code-hooks): the deterministic layer, with the event reference and starter hooks. - [Claude Code plan mode](/blog/claude-code-plan-mode): when to force read-only planning before any edit. - [Claude Code agent teams](/blog/claude-code-agent-teams): what multi-session coordination actually costs. - [Codex vs Claude Code](/blog/codex-vs-claude-code): the comparison to run before committing a team to either. External references: [Claude Code overview](https://code.claude.com/docs/en/overview), [skills](https://code.claude.com/docs/en/skills), [hooks](https://code.claude.com/docs/en/hooks), [subagents](https://code.claude.com/docs/en/sub-agents), [plugins](https://code.claude.com/docs/en/plugins), [MCP](https://code.claude.com/docs/en/mcp) (Anthropic documentation, fetched at time of writing).