What Is Claude Code? The Terminal Agent and Its Extension Model

What Is Claude Code?

Anthropic defines it precisely in the Claude Code overview documentation: "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools." The operative word is agentic, because the tool holds file access, a shell, and an execution environment rather than only a conversation.

The documentation calls Claude Code an agentic harness around the model, meaning the model supplies the reasoning while the harness supplies tools, context management, and somewhere to run. A session moves through three phases: gather context, take action, then verify results.

That division of labour shows up clearly in Anthropic's own usage research. In a study of roughly 400,000 Claude Code sessions from about 235,000 people between October 2025 and April 2026, Anthropic reported that people make about 70% of the planning decisions but only 20% of the execution decisions.

You decide what should happen, and the agent decides how. That is exactly why the extension model matters, because the extension model is where you get to constrain the how.

Claude Code is one of several terminal-first agents that now compete for the same slot in a developer workflow, and our roundup of agentic coding CLI tools covers how the category has settled.

How Does a Claude Code Session Actually Work?

Claude Code reads files on demand rather than building its own index of your repository ahead of time. Its search tools are pattern and regex based, symbol-level navigation comes from separate code intelligence plugins, and the documentation treats a prebuilt code index as something your organisation runs and exposes to the agent instead of something the tool ships.

The consequence is that context is assembled fresh each time, which is why the instruction files described later in this article carry so much weight.

Between reading and writing sits the permission system, which is the setting most teams get wrong on day one. Claude Code documents six permission modes, and the mode you start in depends on your account type rather than on a preference you set.

Pro, Max, and Team plans start in auto mode, where a classifier model reviews actions instead of you, while Enterprise plans and Console API keys start in Manual. In Manual mode the agent is also bounded to the directory it was started in and asks before reading outside it, whereas auto mode reads beyond that boundary without asking.

There is a separate sandbox providing operating-system-enforced filesystem and network isolation for shell commands, and its platform support has a sharp edge worth knowing before you standardise on it.

• macOS - supported through the built-in Seatbelt framework, with nothing extra to install.
• Linux and WSL 2 - supported, and dependent on the bubblewrap and socat packages being present.
• Native Windows - not supported, so a Windows team that wants sandboxed command execution has to run Claude Code inside WSL 2 instead.

Teams that want stronger guarantees than a permission prompt usually reach for hooks, and our guide to pre-action checks for AI coding agents works through the patterns that hold up in practice.

Where Does Claude Code Run?

Claude Code is no longer only a terminal tool, though the terminal remains its most complete surface. Anthropic documents five first-party surfaces plus the Claude mobile apps as a thin client into cloud sessions.

The detail that matters for a team decision is that every surface connects to the same underlying engine, so a repository's CLAUDE.md files, settings, and MCP servers work identically across all of them. Configuring the extension model once means it follows whoever picks up the work, on whichever surface they prefer.

What Is the Claude Code Extension Model?

The extension model is six layers that each plug into a different part of the agentic loop: CLAUDE.md for persistent context, skills for reusable procedures, subagents for isolated work, MCP for external tools, hooks for deterministic enforcement, and plugins for packaging and sharing the rest. Each one lives as an ordinary file inside your repository or home directory, which means it is reviewable and version-controlled like any other code.

---
name: playwright-skill
description: >
  Generates production-grade Playwright automation scripts and E2E tests
  in TypeScript, JavaScript, Python, Java, or C#. Supports local execution
  and TestMu AI cloud across 3000+ browser/OS combinations and real mobile
  devices. Use when the user asks to write Playwright tests, automate
  browsers, run cross-browser tests, test on real devices, debug flaky
  tests, mock APIs, or do visual regression.
languages:
  - JavaScript
  - TypeScript
  - Python
  - Java
  - C#
category: e2e-testing
---

Skip the setup and install the Selenium Skill for Claude Code, Copilot & Cursor with one command.

Try Now!

# Remote server over HTTP
claude mcp add --transport http <name> <url>

# Local server over stdio, with -- separating Claude's flags from the command
claude mcp add <name> -- <command> [args...]

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/check-protected-paths.sh"
          }
        ]
      }
    ]
  }
}

Which Extension Mechanism Should You Use?

Most teams reach for CLAUDE.md first and then keep adding to it until it stops being read carefully. Matching the mechanism to the problem avoids that, and the choice usually comes down to whether you need a fact, a procedure, a capability, or a guarantee.

A practical rule falls out of that table: anything you would be unhappy to discover was skipped belongs in a hook, and everything else can start as a skill.

What Claude Code Cannot Verify About Its Own Work

The third phase of the documented loop is verify results, and it is worth being precise about what that phase can and cannot establish. Claude Code can run your test suite, read the output, and iterate until the output is green, which makes it very good at satisfying checks that already exist.

What it cannot do is act as an independent witness. The same system that wrote the code also decides whether the result counts as passing, so a green run is a self-report rather than a second opinion, and that distinction is the subject of our analysis of whether coding agents can test their own code.

There is a second, more concrete limit. The agent reasons about source text, so its idea of correct comes from compilation, type checks, and assertions rather than from rendered output.

• Browser reality - a component that passes a unit test can still break in Safari, and nothing in the session opened Safari.
• Device reality - layout, gestures, and pixel density behave differently on real Android and iOS hardware than in any local approximation.
• Non-determinism - a flaky test that passed on this run tells you about this run, not about the change.
• Coverage gaps - when the agent writes both the feature and its tests, the untested path is the one neither of them considered.

Note: Claude Code writes the change, and something independent should confirm the application still works. TestMu AI runs that check on real browsers and real devices instead of on the agent's own assumptions. Start free

How Do You Wire Claude Code Into a QA Workflow?

Every layer described above is a file, which means a testing workflow can be distributed the same way a library is. TestMu AI publishes an open-source skill library for exactly this, and the repository below is the one cloned into the .claude/skills directory of the project this article was written in.

The library's own index declares 70 skills across 8 categories, covering api-testing, bdd-testing, cloud-testing, devops, e2e-testing, mobile-testing, unit-testing, and visual-testing, and it ships under the MIT licence at the agent-skills repository. Each framework directory is a SKILL.md plus supporting files, so installing one is a copy rather than an integration.

Three of the extension layers do useful and distinct work once a testing stack is involved.

• Skills for framework conventions - a Selenium or Appium skill carries the setup, cloud configuration, and patterns your team already agreed on, so generated tests match the suite instead of inventing a new style.
• MCP for capability - registering an MCP server gives the agent a tool it did not have, and TestMu AI ships servers for automation, visual testing, and accessibility that list Claude among their supported clients.
• Hooks for the gate - a Stop or PostToolUse hook is where an independent check belongs, because it runs whether or not the agent thought it was necessary.

The verification step itself is where TestMu AI's Kane CLI is designed to sit. It is distributed as the @testmuai/kane-cli package, needs Node.js 18 or later with Chrome on PATH, and runs one binary in three modes: an interactive TUI, a headless CLI, and an agent mode that emits NDJSON specifically so another agent can read the run. It completes up to 50 steps per flow by default, with the ceiling configurable per run through --max-steps.

It also installs as a Claude Code skill, at ~/.claude/skills/kane-cli/SKILL.md globally or .claude/skills/kane-cli/SKILL.md for one project, and Claude Code picks it up without a restart. The Kane CLI documentation covers the install and the flags for each mode.

Being honest about the boundaries matters as much as the capabilities. Kane CLI does not solve CAPTCHAs, does not download files initiated by browser actions, and cannot verify WebGL or 3D scene state, so those flows still need a human or a different approach.

Getting Started With Claude Code

Install the CLI first, because it is the surface where every other piece of the extension model can be tested quickly. The setup documentation lists the native installer as the recommended route, and native installs update themselves in the background.

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# Confirm the install, then check configuration health
claude --version
claude doctor

From there, add the layers in the order that gives you the most return for the least configuration.

• Write a CLAUDE.md under 200 lines covering the conventions a new hire would need, and commit it.
• Check which permission mode your account starts in, because Pro, Max, and Team default to auto rather than Manual.
• Move your most-repeated instruction out of CLAUDE.md and into a skill, so it loads only when it is relevant.
• Install a framework skill that matches your suite, then read the tests it generates before trusting the next batch.
• Add one PreToolUse hook for the rule you would be unhappy to see skipped, and confirm it blocks by triggering it deliberately.
• Put the independent verification step behind a hook rather than in an instruction, so a green result comes from something other than the agent that wrote the code.

The first five steps make Claude Code fit your codebase. The sixth is the one that decides whether you can trust what comes out of it, and it is the step teams skip most often.