Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools, available in the terminal, IDE, desktop app and browser (Source 1). The docs summarise the product with a contrast: unlike inline code assistants that only see the current file, Claude Code sees your whole project, so it can search for relevant files, read several of them, make coordinated edits, run tests, and commit if you ask (Source 2).

Why it exists follows from Chapter 2: in chat the developer is the courier between model and machine. An agent that runs where the code lives removes the courier. Press coverage dates the first public preview to 24 February 2025 (see Chapter 2, Source 4); Anthropic's current documentation no longer labels it a preview. Beyond that, this page does not speculate about Anthropic's motives, since no official statement of them was read.

Claude Code is the layer around the model that provides the tools and manages the context the model sees — the harness (Source 2). The model never touches your machine directly. It asks the harness to call a tool, the harness checks permission, runs it, and returns the result as new context.

Compare this with the generic six-part diagram in Chapter 3: instructions and context are the context manager, tools are the tool runner, the execution environment is your terminal, filesystem and repository, and the feedback loop is the arrow carrying every tool result back to the model. The permission gate is the part that makes it safe to let the loop run.

A repository can be far larger than any context window, so Claude Code does not load it. It explores: it searches for files and content, reads the ones that matter, and follows what it finds — the "gather context" phase of the loop (Source 2). The documentation's recipes for a new project start broad and narrow down:

• Point at files with @. Typing @path includes a file's content directly when it fits the Read tool's limit, 25,000 tokens by default; a text file over 256KB is not included. A directory reference adds a listing, not contents (Source 3).
• Language-aware navigation is optional. The LSP tool provides go-to-definition, find-references and type errors, but is inactive until you install a code-intelligence plugin for your language (Source 4). For a typed language such as Java this can replace several text searches with one lookup.
• Delegate wide exploration. Asking Claude to "use a subagent to investigate" keeps the many file reads in the subagent's own context window and returns only a summary (Source 3).

Tool names are the exact strings used in permission rules, subagent tool lists and hook matchers (Source 4). These are the ones you meet first:

The reference lists many more (task tracking, scheduling, MCP resource access, worktrees and others), grouped in the docs into five capability categories: file operations, search, execution, web and code intelligence (Source 2).

Notice what is not special about tests: there is no built-in test runner. Claude runs whatever your project already runs (for a Spring Boot project, Maven or Gradle through Bash) and reads the output. That is why a project with fast, trustworthy tests is the best environment for an agent.

The diagram restates the loading table from the extension guide (Source 6). Solid fill means "occupies your context"; dashed means "not until needed". Chapter 10 covers each mechanism in depth.

Press Shift+Tab to cycle permission modes. The docs list six (Source 7):

• Rules beat modes. You can allow specific commands (for example npm test) in .claude/settings.json; deny rules apply in every mode (Source 7).
• Checkpoints cover files only. Before editing, Claude snapshots files so Esc twice rewinds them; remote actions such as databases, APIs and deployments cannot be checkpointed (Source 2).
• Sandboxing adds filesystem and network isolation for shell commands; on Windows it is not supported natively, but is in WSL 2 (Source 8, Source 9).

Claude Code works with Git directly: it can see your branch, uncommitted changes and recent history, stage changes, write commit messages, create branches and open pull requests (Source 1, Source 2). In practice you ask in plain language:

• Worktrees for parallel work. claude --worktree feature-auth starts a session in its own git worktree on its own branch, so two sessions do not collide. The repository needs at least one commit first (Source 3).
• Sessions link to pull requests. When Claude creates a PR with gh pr create or glab mr create, the session is linked and can be reopened with claude --from-pr NUMBER (Source 3).
• Attribution lines. Claude Code adds commit and pull-request attribution lines you can change with the attribution setting (Source 2).
• Git is your real undo. Checkpoints are separate from Git and local to the session; commit in small steps so a bad change is a revert, not a rescue.

The following was run while writing this page. It needs no login: it reads the installed CLI's own help text and shows the flags the chapter just described.

What it shows: every concept above has a flag — permission mode, model, effort, resume, worktree — and -p prints a response and exits, which is how Claude Code is used in scripts and CI. No Claude session was started, so nothing here proves how the agent behaves on a task; that is demonstrated in later chapters, and any session output on those pages will be labelled as executed or illustrative.

This is not a contest. The two approaches optimise different things, and Claude Code itself ships an IDE extension that narrows the gap.

The VS Code extension bundles its own copy of the CLI, supports checkpoints and MCP, and adds per-change accept/reject diffs, while a subset of the CLI's commands and features (for example the ! bash shortcut and tab completion) are CLI-only (Source 10). Many developers will use both: the editor for fine edits and review, the agent for multi-step work. Which mix is right is an empirical question for your project.