Anthropic product dossier 060
Claude Code: Agent Architecture, Tools and Product System
How the model, agent loop, repository context, tools, permissions, Skills, MCP, hooks, subagents, plugins, execution environments and Agent SDK fit together.Claude Code in one minute
Claude Code is Anthropic's agentic software-development product and the reference implementation of its reusable agent harness. It combines a selected Claude model with repository context, built-in tools, an execution environment, permissions, session state and an extension system that can inspect, change and verify software.
It is not a model, an IDE, a terminal emulator or the Model Context Protocol. The model reasons; Claude Code manages the loop; the environment contains the code and tools; permissions decide which actions may proceed; integrations extend what the agent can reach; Git and tests provide review and verification boundaries.
Essential questions
| Question | Concise answer |
|---|---|
| Is Claude Code a model, an IDE or an agent system? | It is an agent system that uses Claude models. It can operate through terminals, IDE integrations, desktop and browser surfaces, but the harness—not the interface—manages context, tools, execution, permissions and sessions. |
| Which Claude model does it use? | The selected model depends on product support, configuration and task. Model capability affects reasoning, but Claude Code's tools, permissions, context management and execution environment remain separate product layers; Sections 02 and 03 explain the boundary. |
| Where does code actually execute? | Client tools execute in the environment controlled by the user or hosting application; the model requests actions but cannot directly run client code. Server tools are different because Anthropic performs their internal execution loop; Section 07 maps responsibility. |
| What can Claude Code access by default? | Access depends on the chosen environment and policy. Read-only operations form the conservative baseline, while writes, commands, network access and external tools may require permission, sandbox policy or administrator controls. |
| What is the difference between permissions and sandboxing? | Permissions decide whether a tool or resource may be used. Sandboxing constrains what Bash and its child processes can do at operating-system level; the controls are complementary rather than interchangeable. |
| How do Skills differ from MCP? | A Skill supplies instructions, resources and scripts that teach the agent how to perform a class of work. MCP supplies a standard connection to external tools, resources and prompts; one provides procedural knowledge, the other system access. |
| How do hooks differ from Skills? | A hook runs a deterministic action at a defined lifecycle event. A Skill gives Claude material to interpret and apply, so its use remains model-directed rather than guaranteed merely because an event occurred. |
| What are subagents, agent teams and worktrees? | A subagent performs delegated work in a separate context. An agent team coordinates several workers; a Git worktree isolates files and branches. These mechanisms solve different orchestration and collision problems, as Section 09 details. |
| How does the Claude Agent SDK differ from Claude Code? | Claude Code is Anthropic's finished coding product. The Agent SDK exposes the same core loop, tools and context management as Python and TypeScript libraries so developers can build and operate their own agent applications; Section 10 compares the platform layers. |
| How do local, cloud and Remote Control sessions differ? | Local execution uses the user's machine; cloud execution places the environment on hosted infrastructure; Remote Control links a remote interface to an existing session. The code location, credentials, latency and security boundary therefore differ. |
| What session information is stored? | Claude Code records conversation and tool activity in session data and can use project instructions, auto memory and retrieved context. Storage location, retention and organisational policy depend on the surface and deployment; Section 06 separates these mechanisms. |
| Can Claude Code safely operate autonomously? | It can perform increasingly long workflows, but autonomy is bounded by permissions, sandboxing, credentials, hooks, environment isolation, review and verification. Greater tool reach or longer operation increases the importance of those controls. |
| What does computer use add? | Computer use adds screenshot observation and mouse or keyboard actions for graphical interfaces. It is a client-side tool loop and expands the attack and error surface; it does not replace safer APIs, command-line tools or typed integrations when those exist. |
| What are the principal enterprise risks? | Over-broad credentials, prompt injection, untrusted repositories, unsafe commands, sensitive-data exposure, extension supply chains and inadequate review. Section 11 maps the controls; Section 14 records the unresolved evidence and operating questions. |
The Claude Code system
| Canonical layer | Responsibility | Examples | Authority / boundary | Detailed section |
|---|---|---|---|---|
| 1. Product surfaces | Present and supervise the runtime. | Terminal, IDE, desktop, web, Slack and CI/CD. | The interface does not determine where execution occurs. | 04 |
| 2. Agent orchestration | Delegates and coordinates work across loops. | Main agent, subagents, teams and dynamic workflows. | Context coordination and file isolation are separate concerns. | 09 |
| 3. Context / behaviour | Supplies instructions, knowledge and working state. | CLAUDE.md, Skills, commands, memory and compaction. | Guidance changes behaviour but does not grant authority. | 06, 08, Appendix |
| 4. Tooling / extension | Reads, changes and connects the working environment. | Built-in tools, shell, MCP, hooks and plugins. | The responsible host or server owns each side effect. | 07–08 |
| 5. Control plane | Determines whether and where actions may run. | Permissions, approvals, policy, hooks and sandbox. | Enforced policy can reject a model request. | 11 |
| 6. Agent runtime / model | Assembles context, reasons, requests tools and iterates. | Claude model, agent loop, sessions and checkpoints. | The model proposes; the runtime coordinates. | 05, 10 |
| 7. Environment / external systems | Supply code, data, credentials, execution and side effects. | Repositories, files, processes, APIs and cloud services. | Each retains its own identity, trust and rollback boundary. | 04, 07, 11 |
From terminal preview to agent platform
| Date | Release type | Milestone | What changed | Strategic meaning |
|---|---|---|---|---|
| 24 Feb 2025 | Model + product | Claude Code research preview | Terminal agent introduced with Claude 3.7 Sonnet. | Moved Claude from code suggestion towards repository-level delegated work. |
| 22 May 2025 | Product | General availability | Background tasks, GitHub Actions and native VS Code and JetBrains integrations announced. | Turned the preview into a supported multi-surface product. |
| 20 Aug 2025 | Commercial capability | Business-plan integration | Team and Enterprise premium seats, analytics, managed policy and Compliance API support. | Added organisation governance and observability. |
| 29 Sep 2025 | Product + platform | Claude Code 2.0 and Agent SDK | Checkpoints, subagents, hooks, background tasks and the renamed Agent SDK. | Exposed the harness as a programmable foundation. |
| 3 Feb 2026 | Integration | Xcode Agent SDK integration | Xcode 26.3 integrated the harness and MCP-connected capabilities. | Placed the runtime inside another vendor's environment. |
| 23 Jun 2026 | Product surface | Claude Tag | Slack-based team delegation built from the wider Claude Code direction. | Extended the pattern towards shared team work. |
| 23 Aug 2026 | Product release | Claude Code 2.1.241 | Latest documented release at this research cut. | Shows continuous product shipping independent of model launches. |
Official product explanations
These videos explain the core product and loop; detailed mechanics are developed in the sections below.
Interfaces and execution environments
The interface is where the user interacts; the execution environment is where files, commands and tools actually run. Confusing the two hides important differences in credentials, local configuration, persistence and isolation.
The same agentic loop can appear in a terminal, IDE, desktop app, browser, mobile interface, Slack or CI/CD pipeline. The table records documented surface state as of 24 August 2026; access changes with environment and organisation policy.
| Surface | Status at 24 Aug 2026 | Where work runs | Context and access | Best fit |
|---|---|---|---|---|
| Terminal CLI | Current | Local machine or configured provider | Repository, shell, Git, CLAUDE.md and extensions. | Full interactive development and operations. |
| VS Code | Current | Usually local machine | IDE selection, open files, plans and inline diffs. | Editing and review inside VS Code. |
| JetBrains | Beta plugin | Usually local machine | Selection, diagnostics and IDE diff viewer. | JetBrains development workflows. |
| Desktop app | Current | Local machine or cloud VM | Access depends on local, SSH or remote session type. | Visual review and parallel sessions. |
| claude.ai/code | Research preview | Anthropic-managed cloud | Configured repository and cloud environment. | Asynchronous remote tasks. |
| Remote Control | Research preview | User's machine | Browser or mobile controls a local session. | Remote supervision without moving code. |
| Slack | Current integration | Anthropic cloud | Trusted channel context and web-session controls. | Tasks from team conversations. |
| CI/CD | Current integration | Pipeline runner | Repository token and non-interactive policy. | Triage, review and automation. |
How a task moves through Claude Code
| Stage | Mechanism | Typical evidence | Common failure |
|---|---|---|---|
| Scope | User goal, constraints, policy and success criteria. | Explicit targets and boundaries. | Vague task produces a plausible but wrong outcome. |
| Gather | Search, file reads, Git state, instructions, memory and connected data. | Relevant implementation path and dependency map. | Hidden configuration or indirect dependency is missed. |
| Decide | Reasoning authority: model reasoning selects the next tool and arguments. | Plan or structured tool request. | Correct schema, wrong action or wrong target. |
| Authorise | Authorisation authority: permissions, managed policy, hooks and sandbox boundaries decide whether the request may proceed. | Allow, ask or deny decision. | Over-broad access or prompt fatigue weakens control. |
| Execute | Execution authority: file tool, shell, MCP server, browser, API or server tool performs the effect. | Tool result, changed files, logs or external state. | Partial action, side effect or stale observation. |
| Verify | Verification authority: tests, type checks, builds, browser inspection and review evaluate the outcome. | Reproducible pass/fail evidence and a diff. | Insufficient coverage is mistaken for correctness. |
Context, memory and session state
Claude Code does not place an entire repository permanently inside the model. It begins with instructions and lightweight discovery metadata, then searches and reads relevant material as work proceeds.
Context is finite and operationally important. Conversation history, file contents, command output, instructions, loaded Skills and tool definitions compete for the same window; compaction replaces older detail with a summary. Loading and retention details below are documented state as of 24 August 2026.
| Context source | When it loads | Purpose | Persistence boundary |
|---|---|---|---|
| System and managed instructions | Session start | Product behaviour and organisation policy. | Re-applied independently of conversation compaction. |
| CLAUDE.md | Root instructions at start; nested files as matching paths are used. | Project conventions, commands and architecture. | File-backed and reusable across sessions. |
| Rules | Always or when path frontmatter matches. | Split persistent guidance by topic or file scope. | Path-scoped content reloads when matching files are read. |
| Auto memory | First 200 lines or 25KB of MEMORY.md at start; topic files on demand. | Machine-local project learnings and preferences. | Shared across worktrees of one repository, not machines or cloud environments. |
| Skill metadata | At discovery | Name and description allow relevance matching. | Full Skill body loads only when triggered. |
| MCP tool names | When connected and available | Expose external capabilities for selection. | Returned data enters context only when used. |
| Files and tool results | During work | Current implementation and observations. | Can be cleared, compacted or lost from active detail. |
| Session transcript | Every turn | Resume, rewind and fork an interaction. | Local JSONL by default; 30-day cleanup is configurable. |
Tools and execution responsibility
| Primitive | Architectural role | What it is | Execution or invocation | Boundary |
|---|---|---|---|---|
| Built-in agent tools | Core | Capabilities directly exposed by Claude Code. | Read, search, edit, Bash, web and delegation calls. | Product permissions and hooks apply; sandbox scope depends on the tool. |
| Shell / programs | Core execution | Software reached through the shell execution tool. | Git, tests, build tools, scripts and system utilities run in the host environment. | The called program inherits available files, processes, credentials and network within enforced limits. |
| MCP tools | Integration | Capabilities advertised by an external MCP server. | Claude Code calls a local or remote server. | Server identity, credentials, data handling and side effects remain external trust decisions. |
| Hooks | Control | Lifecycle automation and enforcement. | Claude Code invokes a command, HTTP request, MCP call, prompt or agent at a matching event. | Deterministic trigger does not make hook code or model-based evaluation inherently safe. |
| Skills / instructions | Extension | Reusable behaviour, context and procedures. | Loaded when relevant or invoked by the user. | They guide model behaviour; they are not an enforced permission boundary. |
| Commands | Convenience / control | User-facing workflow or product invocation. | Built-in commands operate product functions; custom commands share the Skills mechanism. | A command name is an entry point, not a separate execution layer. |
| Subagents | Orchestration | Delegated agent contexts. | A separate loop works and returns a result to the caller. | Context isolation is distinct from filesystem or credential isolation. |
| Agent teams | Orchestration | Coordinated independent sessions. | A lead, teammates, shared tasks and messaging coordinate work. | Experimental; coordination does not automatically isolate files. |
| Agent SDK | Programmatic interface | Embedding and control interface for agent applications. | Python or TypeScript application hosts the harness. | The application operator owns process, environment, identity and deployment security. |
Computer use as the broad fallback
Computer use can reach interfaces without a purpose-built API, but screenshot interpretation and many small actions make it slower and harder to constrain. A typed tool or MCP integration is normally preferable when one exists.
The extension system: what each piece is for
| Extension | Architectural role | Status at 24 Aug 2026 | Primary function | Execution / loading boundary |
|---|---|---|---|---|
| CLAUDE.md | Core context | Current | Persistent project instructions. | Loads into context at session start or path discovery. |
| Skills | Extension | Current | Reusable knowledge, procedures and optional scripts. | Metadata loads first; full resources load on demand. |
| MCP | Integration | Current | Connects hosts to external tools, resources and prompts. | A local process or remote HTTP server owns its capabilities. |
| MCP Inspector | Diagnostic convenience | Development tool | Inspects and exercises an MCP server. | Runs as a web, CLI or terminal test interface. |
| Hooks | Control | Current; agent hooks experimental | Deterministic lifecycle automation and enforcement. | Runs a command, HTTP request, MCP call, prompt or agent at an event. |
| Subagents | Orchestration | Current | Focused workers with separate context. | A separate loop runs; its result returns to the caller. |
| Plugins | Extension distribution | Current | Packages versioned extension sets. | Can load Skills, agents, hooks, MCP and LSP components. |
| Code intelligence | Integration | Current; plugin-dependent | Provides symbol navigation and diagnostics. | Runs through a language-server integration. |
Subagents, teams and parallel work
Parallelism has two separate problems: coordinating reasoning and isolating file changes. Subagents, dynamic workflows and agent teams address coordination; Git worktrees and separate environments prevent concurrent edits from colliding.
More agents do not automatically improve quality. Coordination consumes tokens, adds latency and creates reconciliation work. Use parallelism where tasks are separable or independent evidence is valuable.
| Mechanism | Status at 24 Aug 2026 | Context isolation | Coordination mechanism | Lifecycle / ownership |
|---|---|---|---|---|
| Background shell command | GA · product-native | None; it is a process, not an agent. | Main session monitors command output. | Owned by the spawning session and host process. |
| Subagent | GA · product-native | Separate context; optional worktree. | Caller delegates; result returns to caller. | Child loop owned by one parent session. |
| Dynamic workflow | Documented capability | Many subagent contexts; isolation is configured. | Scripted fan-out, aggregation and verification. | Workflow script owns worker creation and completion. |
| Agent view | Research preview | Independent sessions with worktrees when editing. | User dispatches, monitors and intervenes. | Each session persists independently under user ownership. |
| Agent team | Experimental · disabled by default | Independent contexts; no automatic file isolation. | Lead, shared tasks and peer messaging. | Team lead coordinates; teammates have separate lifecycles. |
| Manual parallel sessions | Documented pattern | Independent sessions and optional worktrees. | User coordination; optional cross-session messages. | User owns start, supervision and shutdown. |
| Parallel tool calls | Runtime behaviour | One agent context. | One model turn requests independent tools concurrently. | One session owns every call; no agent dialogue. |
| SDK-orchestrated agents | SDK capability | Application-defined contexts and environments. | Application code defines delegation and messaging. | Application operator owns process, identity and shutdown. |
Claude Agent SDK and adjacent platform layers
The Claude Agent SDK exposes the same tools, loop and context management that power Claude Code as Python and TypeScript libraries. It turns the harness into an application component, but the developer must operate its process, environment, credentials and security boundary.
This is different from a normal Claude client SDK, where the application implements the tool loop, and from Managed Agents, where Anthropic operates the agent and sandbox behind a hosted API. The comparison records platform state as of 24 August 2026.
| Layer | Status at 24 Aug 2026 | Interface | Who runs the loop | Who runs the environment | Primary use |
|---|---|---|---|---|---|
| Claude Code | Current product | CLI, IDE, desktop, web and integrations | Anthropic product harness | User or Anthropic cloud | Interactive and delegated software work. |
| Claude Agent SDK | Current SDK | Python or TypeScript library | Bundled harness in the application process | Developer | Custom agents and automation. |
| Anthropic Client SDK | Current API SDK | Messages API client | Developer application | Developer for client tools; Anthropic for server tools | Explicit custom orchestration. |
| Managed Agents | Beta API | Hosted REST API | Anthropic | Anthropic-managed sandbox | Asynchronous agents without self-hosting. |
| MCP | Current protocol integration | Open JSON-RPC protocol | Host application | Each server operator | External capabilities, not a complete harness. |
Security, permissions and enterprise control
| Control | What it controls | Important limit |
|---|---|---|
| Manual permissions | Read-only baseline with approval for edits and non-read-only commands. | Repeated prompts can produce unsafe blanket approvals. |
| Permission rules | Deny, ask and allow by tool, command, path, domain or MCP capability. | Pattern quality determines coverage; deny rules should protect high-risk paths. |
| Auto mode | Separate classifier reviews actions and blocks those judged unsafe. | Not a substitute for explicit organisation policy or human approval of irreversible actions. |
| Bash sandbox | OS-level filesystem and network isolation for shell commands and child processes. | Does not govern every non-Bash tool; availability differs by operating system. |
| Hooks | Pre- and post-action enforcement, validation, logging and notification. | Hook code is trusted code and must itself be secured and versioned. |
| Managed settings | Organisation-wide permissions, sandbox, MCP, plugin and bypass policy. | Correct deployment and precedence must be verified on every supported platform. |
| Checkpointing | Snapshots Claude's file edits before changes. | Does not cover user edits, every shell side effect or external systems; Git remains necessary. |
Who buys it, who uses it and where it fits
| Customer or channel | Users | How Claude Code fits | Evidence boundary |
|---|---|---|---|
| Individual subscription or API account | Developer, analyst, founder or technical operator | Local or cloud coding, research and automation. | Plan and surface determine usage and provider access. |
| Team / Enterprise organisation | Engineering and technical teams | Premium seats, managed policy, analytics and compliance controls. | Organisation access does not prove safe project configuration. |
| Accenture | Consultants and enterprise-development teams | Large training and deployment partnership centred on Claude Code. | Deployment and market-share statements are company-reported. |
| PwC | Engineering, finance and client-delivery teams | Claude Code, Cowork and Claude used across internal and client workflows. | Reported delivery gains are deployment-specific, not universal benchmarks. |
| TCS / Cognizant / Infosys | Services teams and regulated-industry clients | Agentic engineering, modernisation and governed client delivery. | Partner reach is distribution capacity, not guaranteed end-customer adoption. |
| Apple Xcode | Apple-platform developers | Agent SDK embeds the harness; MCP connects Claude Code to Xcode capabilities. | Xcode remains Apple's product; the SDK is the integration layer. |
| CI/CD and platform teams | Repository maintainers and automation owners | Issue triage, review, scheduled checks and repository changes. | Service accounts and unattended actions require stricter policy than interactive use. |
Product direction and dependency gates
Claude Code is best understood as a programmable agent runtime whose first-class operating environment is software development—not simply as a terminal interface to Claude. Local, cloud, embedded and team capabilities support this interpretation, but do not constitute a dated promise of future delivery.
Its architecture is moving from single-agent interaction towards composable orchestration: model + tools + external context + deterministic controls + delegated agents + programmatic interfaces.
| Workstream | Current state | Published direction | Required gate | What it enables |
|---|---|---|---|---|
| Interfaces | Terminal, IDE, desktop, web, mobile control, Slack and CI/CD | One loop across more work surfaces. | Consistent policy and traceability across environments. | Work can begin, continue and be reviewed where teams already operate. |
| Execution | Local, Anthropic cloud, self-hosted cloud and Remote Control | More asynchronous and remotely supervised work. | Isolation, reproducibility, credential and network controls. | Longer tasks without tying work to one terminal session. |
| Orchestration | Subagents, dynamic workflows, teams and cross-session messaging | Parallel specialists and coordinated task graphs. | Task decomposition, conflict prevention and result reconciliation. | Larger audits, migrations and feature programmes. |
| External action | MCP, plugins, browser and computer use | Broader work across business systems. | Trusted integrations, least privilege and prompt-injection resistance. | End-to-end workflows beyond repository files. |
| Embedded agents | Agent SDK and Managed Agents | Claude Code-class harnesses inside third-party and enterprise products. | Stable APIs, hosting, observability and commercial controls. | Domain agents that reuse the same execution architecture. |
| Team work | Claude Tag, Slack and organisation policy | Proactive agents participating in shared workflows. | Identity, channel memory, ownership and escalation design. | Delegation beyond the individual developer-agent relationship. |
Strategic synthesis
| Question | Evidence-led conclusion |
|---|---|
| What is technically different? | Claude Code is a programmable agent runtime whose first-class operating environment is software development. Its iterative loop combines repository-scale context, direct tools, execution environments, extensions and deterministic controls; the terminal is one surface, not the architectural boundary. |
| Where may defensibility sit? | In model capability combined with runtime quality, workflow integration, developer adoption, extension distribution and enterprise controls. This is an analytical inference, not a disclosed moat. |
| What are the dependencies? | Claude model and API/cloud availability; local or hosted execution; repository and credential hygiene; external tools and MCP servers; and the developer ecosystem. |
| What is the trajectory? | The evidence supports a move from interactive coding agent towards a general-purpose agent runtime optimised first for software-engineering environments. Wider use still depends on secure execution and domain-specific verification. |
Key risks and unresolved questions
- Incorrect but plausible changes. Repository access and tool use increase the scale of work, not the certainty that the work is correct.
- Prompt injection. Repositories, web pages, MCP results, issue text and documents can contain instructions that conflict with the user's intent.
- Credential and data exposure. Shells, integrations and browser sessions can reach secrets or proprietary material if boundaries are weak.
- Irreversible side effects. Checkpoints cover Claude file edits, not every shell command, deployment, database change or external API action.
- Context loss. Long sessions compact detail; early instructions and evidence can be summarised or omitted unless stored durably.
- Extension supply chain. Plugins, Skills, MCP servers and hooks introduce code, network dependencies and trust relationships outside Anthropic.
- Surface inconsistency. Local, cloud, web, IDE, Slack and embedded SDK deployments do not have identical access, controls or persistence.
- Cost and latency. Long context, repeated tool loops, parallel agents and verification can make simple work slower or more expensive than direct methods.
- Measurement quality. Lines changed, acceptance rate or self-reported productivity do not establish maintainability, defect rates or business value.
- Fast-changing specification. Claude Code ships frequently; version-specific behaviour can change faster than enterprise policy and training.
Primary sources
- Claude Code overviewCurrent product definition, interfaces and installation.
- How Claude Code worksAgent loop, environments, sessions, context and project access.
- Claude Code changelogCurrent release and product-level shipping cadence.
- Claude 3.7 Sonnet and Claude CodeFebruary 2025 research-preview launch.
- Introducing Claude 4General availability, IDE and GitHub Actions milestone.
- Claude Code for Team and EnterpriseBusiness seats, analytics, managed policy and Compliance API.
- Enabling Claude Code to work more autonomouslyVersion 2.0, checkpoints, subagents, hooks, background tasks and Agent SDK.
- Extend Claude CodeCLAUDE.md, Skills, MCP, hooks, agents, plugins and code intelligence.
- Platforms and integrationsCurrent CLI, desktop, IDE, web, mobile, Slack and CI/CD surfaces.
- Remote ControlResearch-preview status and local-execution boundary.
- Hooks referenceLifecycle events, hook types and experimental agent-hook status.
- Run agents in parallelCurrent distinction among subagents, agent view, dynamic workflows, teams, worktrees and background commands.
- Agent teamsExperimental status, independent contexts, shared tasks, messaging and known limitations.
- Claude Code context windowStartup context, progressive loading and compaction behaviour.
- Claude Code memoryCLAUDE.md, auto memory and machine-local persistence.
- Claude Code sessionsResume, fork, transcripts, retention and context controls.
- Claude Code checkpointingFile-edit snapshots, rewind and coverage boundaries.
- How tool use worksClient tools, server tools, execution responsibility and loops.
- Computer use toolClient-side visual action contract and environment boundary.
- Agent Skills overviewSKILL.md, progressive disclosure and product surfaces.
- MCP architecture, 28 July 2026Current stateless host-client-server protocol and security roles.
- MCP InspectorCurrent development and server-testing tool.
- MCP in Claude CodeServer configuration, scopes, trust, authentication and tool access.
- Claude Agent SDK overviewProgrammable harness, interfaces and product boundaries.
- Hosting the Agent SDKPersistent environments, container isolation and deployment patterns.
- Claude Code securityPermission architecture, prompt injection and user responsibility.
- Claude Code permissionsDeny, ask, allow, sandbox interaction and managed settings.
- Organisation deploymentIdentity, provider and managed-policy options.
- Claude Agent SDK in XcodeThird-party embedding and MCP integration boundary.
- Introducing Claude TagTeam delegation and published evolution from Claude Code.
- Claude Code commandsCanonical built-in commands, bundled Skills, dynamic workflows, aliases, availability and removed commands.
- Extend Claude Code with SkillsCustom slash invocation, legacy command compatibility, Skill scope and dynamic discovery.
Appendix: Claude Code slash-command reference
Slash commands operate the session and product; they are not the tools that execute the agent's work. Built-in commands run fixed product behaviour, bundled Skills supply prompt-based workflows, and dynamic workflows coordinate background agents. User Skills, plugins and MCP servers can add further commands.
This is the complete canonical command set documented by Anthropic on 24 August 2026. Availability varies by release, operating system, plan, provider, feature flag and execution surface. Type / in the active session to see the commands actually available there.
Session, context and task control
| Command | Command type | Purpose | Arguments / aliases | Availability boundary |
|---|---|---|---|---|
| /add-dir | Built‑in | Add another working directory for this session. | <path> | Current session; added-directory configuration is only partly discovered. |
| /autocompact | Built‑in | Set or inspect the automatic compaction threshold. | [auto|<tokens>] | Claude Code 2.1.221+. |
| /background | Built‑in | Detach the current session as a background agent. | [prompt] · /bg | Background-agent support required. |
| /branch | Built‑in | Branch the conversation at its current point and switch to the branch. | [name] | Current session history. |
| /btw | Built‑in | Ask a side question without adding it to conversation history. | [question] | Claude Code 2.1.212+ for optional empty invocation. |
| /cd | Built‑in | Move the session to another working directory while retaining its conversation. | <path> | Claude Code 2.1.169+; subject to trust and Cd permission rules. |
| /clear | Built‑in | Start a new conversation with empty context while retaining the previous session. | [name] · /reset · /new | Use /compact when continuity matters. |
| /compact | Built‑in | Summarise the current conversation to release context capacity. | [instructions] | All supported interactive sessions. |
| /context | Built‑in | Visualise what occupies the current context window. | [all] | Presentation varies by terminal renderer. |
| /copy | Built‑in | Copy a recent assistant response or selected code block. | [N] | Clipboard or file-writing support depends on the environment. |
| /exit | Built‑in | Exit the CLI; detach rather than stop an attached background session. | /quit | CLI surfaces. |
| /export | Built‑in | Export the current conversation as plain text. | [filename] | Interactive copy/save dialog when no filename is supplied. |
| /fork | Built‑in | Copy the conversation into a separate background session. | [prompt] | Claude Code 2.1.212+; behaviour differs when agent view is disabled. |
| /goal | Built‑in | Set, inspect or clear a persistent completion condition. | [condition|clear] | Goal-enabled releases. |
| /recap | Built‑in | Generate a one-line summary of the current session. | None | Current supported sessions. |
| /rename | Built‑in | Name or automatically name the current session. | [name] | Non-interactive support requires 2.1.205+. |
| /resume | Built‑in | Resume a stored conversation by identifier, name or picker. | [session] · /continue | A running background session must be attached or stopped first. |
| /rewind | Built‑in | Restore conversation and/or code to a checkpoint, or summarise from one. | /checkpoint · /undo | File rollback does not reverse every external side effect. |
| /stop | Built‑in | Stop the current attached background session while retaining its transcript and worktree. | None | Only while attached to a background session. |
| /subtask | Built‑in | Spawn a forked subagent whose result returns to the current conversation. | <task> | Claude Code 2.1.212+ with agent view enabled. |
| /tasks | Built‑in | View and manage the current session's background work. | /bashes | Includes completed subagents and background commands. |
Models, interface, account and usage
| Command | Command type | Purpose | Arguments / aliases | Availability boundary |
|---|---|---|---|---|
| /advisor | Built‑in | Enable, disable or choose the second-model advisor. | [model|off] | Model access dependent; Fable requires Fable 5 access. |
| /artifacts | Built‑in | List and attach available Claude artifacts. | None | Only where artifacts are supported; 2.1.208+. |
| /color | Built‑in | Set the current session's prompt-bar colour. | [colour|default] | 2.1.205+; also available in non-interactive mode. |
| /config | Built‑in | Open settings or set supported values directly. | [key=value ...] · /settings | Direct key/value control requires 2.1.181+. |
| /desktop | Built‑in | Continue the session in Claude Code Desktop. | /app | macOS or x64 Windows with a Claude subscription. |
| /effort | Built‑in | Set or inspect model reasoning effort. | [level|auto|status] | Levels depend on the selected model and account. |
| /fast | Built‑in | Toggle fast mode. | [on|off] | Claude Code 2.1.205+; surface and plan dependent. |
| /focus | Built‑in | Toggle the reduced-noise conversation view. | None | Fullscreen renderer only; VS Code has its own control. |
| /help | Built‑in | Show help and commands available in the current environment. | None | Live availability is environment-specific. |
| /keybindings | Built‑in | Open or create the keyboard-shortcut configuration. | None | Interactive local surfaces. |
| /login | Built‑in | Sign in to an Anthropic account. | None | Authentication method depends on deployment. |
| /logout | Built‑in | Sign out of the current Anthropic account. | None | First-party account sessions. |
| /mobile | Built‑in | Show a QR code for the Claude mobile application. | /ios · /android | First-party distribution surfaces. |
| /model | Built‑in | Select a model and, where supported, its effort level. | [model] | Available models depend on provider, plan and policy. |
| /passes | Built‑in | Share an eligible free Claude Code access period. | None | Only visible to eligible accounts. |
| /privacy-settings | Built‑in | View and change account privacy settings. | None | Pro and Max subscribers. |
| /radio | Built‑in | Open the Claude FM stream. | None | Unavailable through Bedrock, Google, Foundry and AWS platform providers. |
| /release-notes | Built‑in | Browse Claude Code release notes. | None | Shown locally without entering the model conversation. |
| /remote-control | Built‑in | Expose the local session through claude.ai Remote Control. | /rc | Claude subscription and sign-in required. |
| /remote-env | Built‑in | Select the default environment for cloud agents. | None | Cloud-agent access required. |
| /scroll-speed | Built‑in | Adjust mouse-wheel scrolling interactively. | None | Fullscreen renderer; unavailable in JetBrains terminal. |
| /status | Built‑in | Show version, model, account, connectivity and session kind. | None | Can open while Claude is responding. |
| /statusline | Built‑in | Configure the terminal status line. | [description] | Terminal surfaces. |
| /stickers | Built‑in | Open the Claude Code sticker-ordering flow. | None | Region and account dependent. |
| /teleport | Built‑in | Pull a Claude Code web session into the terminal. | /tp | Claude subscription required. |
| /terminal-setup | Built‑in | Configure terminal-specific input shortcuts. | None | Only shown in terminals that need it. |
| /theme | Built‑in | Select a built-in, accessible, ANSI or custom theme. | None | Interactive local surfaces. |
| /tui | Built‑in | Select and relaunch the terminal renderer. | [default|fullscreen] | Terminal surfaces. |
| /upgrade | Built‑in | Open the account plan-upgrade flow. | None | Hidden on Enterprise plans. |
| /usage | Built‑in | Show usage, session cost and activity statistics. | /cost · /stats | Detail varies by plan and billing route. |
| /usage-credits | Built‑in | Configure or request additional usage credits. | None | Billing permissions determine whether settings or an admin request opens. |
| /voice | Built‑in | Enable, configure or disable voice dictation. | [hold|tap|off] | Claude.ai account required. |
Project configuration, access and extensions
| Command | Command type | Purpose | Arguments / aliases | Availability boundary |
|---|---|---|---|---|
| /agents | Built‑in | Guide creation or management of subagent definitions. | None | 2.1.198+ directs users to conversation or configuration files. |
| /auto-mode-setup | Built‑in | Draft and review an auto-mode environment policy. | None | Pro, Max or Team; version and native-Windows requirements apply. |
| /chrome | Built‑in | Configure Claude in Chrome. | None | Chrome integration required. |
| /hooks | Built‑in | Inspect configured lifecycle hooks. | None | Current hook-enabled releases. |
| /ide | Built‑in | Manage IDE integrations and inspect their status. | None | Local supported IDE environments. |
| /import | Built‑in | Import compatible Codex or Gemini configuration. | [codex|gemini] [--dry-run] [--yes] | 2.1.213+; unavailable on third-party model providers. |
| /init | Built‑in | Create a project CLAUDE.md and offer supported configuration migration. | None | Repository or project working directory. |
| /mcp | Built‑in | Inspect, authenticate, enable, disable or reconnect MCP servers. | [reconnect <server>|enable|disable [<server>|all]] | Interactive and, from 2.1.205, non-interactive status mode. |
| /memory | Built‑in | Edit CLAUDE.md files and inspect or control auto memory. | None | Persistence depends on configuration scope and environment. |
| /permissions | Built‑in | Manage allow, ask and deny rules plus working-directory access. | /allowed-tools | Organisation policy can constrain editable scopes. |
| /plugin | Built‑in | List, install, enable or disable Claude Code plugins. | [subcommand] | Plugin support and marketplace policy required. |
| /reload-plugins | Built‑in | Reload active plugins without restarting the session. | [--force] | Force may invalidate the prompt cache when MCP tools change. |
| /reload-skills | Built‑in | Re-scan Skill and legacy command directories. | None | Claude Code 2.1.152+. |
| /sandbox | Built‑in | Toggle operating-system sandbox mode. | None | Supported platforms only. |
| /setup-bedrock | Built‑in | Configure Amazon Bedrock credentials, region and model pins. | None | Hidden until Bedrock mode is enabled. |
| /setup-vertex | Built‑in | Configure Google Cloud authentication, project, region and models. | None | Hidden until Vertex mode is enabled. |
| /skills | Built‑in | List, filter and control visibility of available Skills. | None | Results include bundled, personal, project and installed Skills. |
Development, orchestration, diagnostics and integrations
| Command | Command type | Purpose | Arguments / aliases | Availability boundary |
|---|---|---|---|---|
| /autofix-pr | Built‑in | Launch a cloud session that watches and fixes an open pull request. | [prompt] | GitHub CLI and Claude Code on the web required. |
| /batch | Skill | Decompose a large change into parallel worktree-backed units. | <instruction> | Git repository required; proposes 5–30 units before execution. |
| /bug | Built‑in | Report a bug or share selected conversation context. | [report] · /share | Delivery route depends on authentication and provider. |
| /claude-api | Skill | Load API guidance or run supported migration and onboarding workflows. | [migrate|upgrade|managed-agents-onboard|prompt-audit] | Subcommand version requirements apply. |
| /code-review | Skill | Review a diff, path, branch or pull request and optionally apply or publish findings. | [effort] [--fix] [--comment] [target] · /review · /ultrareview | Ultra uses a cloud review; GitHub posting requires suitable access. |
| /dataviz | Skill | Apply chart-selection, colour, interaction and accessibility guidance. | [request] | Claude Code 2.1.198+. |
| /debug | Skill | Enable session debug logging and diagnose the resulting log. | [description] | Only events after logging begins are captured. |
| /deep-research | Workflow | Fan out web research and synthesise a cited report. | <question> | User-invoked background workflow. |
| /design-login | Built‑in | Authorise access used by the design-system synchronisation workflow. | None | Claude Design access required. |
| /design-sync | Skill | Validate and upload a repository's React design system to Claude Design. | [hint] | Unavailable where the configured provider cannot reach claude.ai. |
| /diff | Built‑in | Open the interactive repository and per-turn diff viewer. | None | Git-backed local workspaces. |
| /doctor | Skill | Diagnose installation, configuration and context-cost problems and propose fixes. | /checkup | Interactive Skill; terminal command also provides read-only diagnostics. |
| /feedback | Built‑in | Send product feedback with an explicit consent step. | [report] | Uses the same delivery rules as /bug. |
| /fewer-permission-prompts | Skill | Analyse transcripts and propose a narrow read-only permission allowlist. | None | Writes only after review and approval. |
| /heapdump | Built‑in | Create memory diagnostics for Claude Code itself. | None | Hidden command; heap snapshots may contain secrets and conversation data. |
| /insights | Built‑in | Generate a local HTML report on usage patterns and friction. | None | Unavailable in cloud sessions. |
| /install-github-app | Built‑in | Install the Claude GitHub App and optionally configure Actions. | None | GitHub account and repository access required. |
| /install-slack-app | Built‑in | Install and authenticate the Claude Slack application. | None | Slack workspace authorisation required. |
| /list-agents | Built‑in | List messageable subagents, teammates and Claude Code sessions. | /peers | 2.1.224+ with cross-session messaging enabled. |
| /loop | Skill | Repeat a prompt or maintenance check while the session remains open. | [interval] [prompt] · /proactive | Self-pacing and autonomous defaults depend on feature availability. |
| /plan | Built‑in | Enter plan mode and optionally begin with a supplied task. | [description] | Supported interactive surfaces. |
| /powerup | Built‑in | Open interactive Claude Code feature lessons. | None | Requires the lesson interface. |
| /run | Skill | Launch and drive the project application to observe a change. | None | Needs a runnable project and suitable execution environment. |
| /run-skill-generator | Skill | Create project-specific instructions for /run and /verify. | None | Requires a project whose launch and verification path can be taught. |
| /schedule | Built‑in | Create, inspect or run cloud routines. | [description] · /routines | Anthropic cloud infrastructure and connected account required. |
| /security-review | Built‑in | Review the branch diff for security vulnerabilities. | None | Requires an origin remote and resolvable default branch. |
| /simplify | Skill | Run parallel cleanup reviews and apply approved simplifications. | [target] | Current versions separate cleanup from correctness review. |
| /team-onboarding | Built‑in | Build a team guide from recent Claude Code usage. | None | Share links require eligible Pro, Max, Team or Enterprise accounts. |
| /verify | Skill | Build, run and observe a change rather than relying only on static checks. | None | User-invoked; requires a verifiable project environment. |
| /web-setup | Built‑in | Connect GitHub credentials for Claude Code on the web. | None | Local GitHub CLI credentials required. |
| /workflows | Built‑in | Open the workflow progress view to monitor, pause, resume or save workflows. | None | Dynamic-workflow support required. |