hidekazu-konishi.com

Claude Code Features and Settings Reference 2026

First Published: 2026-05-16
Last Updated: 2026-05-16

* The contents of this article reflect the state as of the Last Updated date shown above. Claude Code ships fast; rows are revised in place as features GA or are deprecated.

This article is a single-page reference of the user-visible surface of Claude Code: distribution channels, built-in tools, plan mode, subagents, skills, hooks, slash commands, MCP integration, settings keys, and keybindings.

It is designed to be consulted, not read end-to-end. Every section is structured as a flat table so that one fetch resolves many separate questions. The first review of this snapshot was completed on 2026-05; subsequent refreshes within the publication year overwrite this page in place at the same URL.

If you have not used Claude Code before, the companion getting-started article walks through installation and a first session. If you are responsible for configuring Claude Code for a team, the harness and environment engineering article covers the operational design that this reference page only catalogs.

• Companion entry point: Claude Code Getting Started - Why Knowing About Local AI Agents Changes Everything
• Companion design guide: Claude Code Harness and Environment Engineering: Designing the Frontline Where Local AI Agents Actually Live

1. How This Snapshot Was Compiled

This page is an annual snapshot refreshed in place as needed. Its goal is to let an engineer (or an AI agent acting on their behalf) answer "what does Claude Code currently expose?" in a single fetch, with each row linking back to the official documentation for verification.

1.1 Scope of the Snapshot

The reference covers the user-visible surface of the official Anthropic distribution of Claude Code:

• All channels through which Claude Code is shipped (CLI, IDE extensions, desktop, web, SDK, CI integrations).
• All settings keys read by the harness from settings.json files at user, project, and local scope.
• All lifecycle events that can be intercepted with hooks.
• All built-in slash commands that ship with the CLI.
• All client-side MCP knobs that determine how external tool servers are wired in.
• Default keybindings for terminal and IDE surfaces.

It does not cover:

• Step-by-step installation, authentication, or first-session guidance. See Claude Code Getting Started.
• Worked examples of hooks, permission rule design, sandbox patterns, or CLAUDE.md templates. See Claude Code Harness and Environment Engineering.
• Pricing, plan tiers, or per-token economics. Those change too quickly to belong in a year-stable reference.

1.2 Sources and Verification

The primary source for every row is the official Claude Code documentation at https://docs.claude.com/en/docs/claude-code/, supplemented by Anthropic engineering posts that announce new features. Every catalog row links to a docs anchor wherever a stable anchor exists.

Items whose presence is observable in the CLI but whose documentation page may shift between minor releases are flagged [Tracking] so you re-check the canonical page on the next review. Features that are present only in a preview or experimental channel are flagged [Preview]. Features announced for removal are flagged [Deprecating].

1.3 Refresh Cadence

This snapshot is refreshed as needed within the publication year. Last reviewed: 2026-05. The URL is intentionally stable across refreshes; new entries are added to the appropriate catalog and removed entries are moved to Recent Deprecations for one cycle before being retired.

1.4 How to Read the Catalogs

Every catalog in this article follows the same shape:

• One row per entity.
• Identical columns across rows so the table can be scanned vertically.
• A short rationale or behavior summary in plain English.
• A link to the canonical documentation page.

Where a feature has multiple aliases, the row uses the name that appears in the CLI prompt or settings file, with the documentation name in parentheses.

2. Distribution Channels

Claude Code is the same engine reached through several surfaces. Each surface exposes a subset of the full feature catalog. This table answers "where can I use Claude Code, and what do I gain or lose by choosing a particular channel?"

* You can sort the table by clicking on the column name.

Channel	Form Factor	Primary Install	Auth	Tools Surface	IDE Integration	Notable Channel-Only Features	Status
CLI	Terminal program (claude)	Native installer (macOS/Linux/Windows) or npm install -g @anthropic-ai/claude-code	Browser OAuth (Claude.ai) or API key	Full	Indirect (works alongside any editor)	The reference surface; everything else mirrors it	GA
VS Code Extension	Editor sidebar and inline chat	VS Code Marketplace ("Claude Code")	Inherits CLI auth	Full, plus IDE-aware diff preview	Native (VS Code, Cursor, Windsurf, etc.)	Live diff overlay, native selection context	GA
JetBrains Plugin	IDE tool window	JetBrains Marketplace ("Claude Code")	Inherits CLI auth	Full	Native (IntelliJ, PyCharm, GoLand, Rider, WebStorm, etc.)	IDE selection context bridging, refactor preview	GA
Desktop App	Standalone GUI (macOS and Windows)	Anthropic-signed installer	Anthropic account	Full, plus session manager and project switcher	None	Multi-project session list, GUI-managed environments	GA
Web (claude.ai/code)	Browser surface on claude.ai	None (open https://claude.ai/code)	Anthropic account	Reduced (no local file system; cloud sandbox only)	None	Shareable conversation links, zero install	GA
Claude Agent SDK	TypeScript and Python libraries	npm install @anthropic-ai/claude-agent-sdk / pip install claude-agent-sdk	API key	Programmable; you compose tools yourself	None	Embed Claude Code as a building block in your own product	GA
GitHub Action	CI step	Marketplace action anthropics/claude-code-action	API key in repo secrets	Full, scoped to checked-out workspace	None	Pull-request reviews, automated diffs in CI	GA
GitHub App	Hosted bot	Install via /install-github-app from the CLI	OAuth plus GitHub	Same as Action, scoped per repository	None	Issue and PR triage from chat	GA

For a feature-by-channel matrix that distinguishes "supported", "partial", and "absent" at the individual tool level, see Section 3 below. The summary version: the CLI is the reference channel, the IDE extensions and Desktop app surface the full toolset, the Web surface is intentionally read-only against your local machine, and the SDK is for embedding rather than direct use.

3. Core Features

The core features below are the units that show up as either a built-in tool, an internal mode, or an explicit user-visible mechanism. Each row is independent and self-contained.

3.1 Built-in Tools

These tools are always present in a Claude Code session (subject to per-tool permission rules). They are the building blocks that every higher-level feature composes against.

* You can sort the table by clicking on the column name.

Tool	Purpose	Side Effect	Permission Surface	Common Uses
Read	Read a file from the local filesystem	None	Read-only by default; no permission needed	Source code review, log inspection, configuration auditing
Edit	Exact string replacement in an existing file	Modifies file	Prompts for approval unless allowed	Targeted bug fixes, rename, refactor lines
Write	Create or overwrite a file	Modifies file	Prompts for approval unless allowed	New files, full rewrites
Bash	Run a shell command	Anything the shell can do	Prompts per command pattern	Test runs, builds, git, package managers
Glob	Match file paths by pattern	None	Read-only	Locate files by pattern
Grep	Search file contents with ripgrep	None	Read-only	Find symbol or string across repo
NotebookEdit	Modify cells in a Jupyter notebook	Modifies file	Prompts for approval	Notebook authoring
WebFetch	Fetch a URL and process it	Network request	Per-domain permission	Read public docs, fetch a known URL
WebSearch	Issue a web search	Network request	Permission-controlled	Look up unknown topics
Task (Agent)	Launch a subagent	Spawns a child session	Inherits subagent permissions	Parallel research, scoped editing
TodoWrite	Create or update a session todo list	Updates internal state	None	Track multi-step work
BashOutput	Read output from a backgrounded shell command	None	Read-only	Inspect long-running command output
KillShell	Terminate a backgrounded shell by ID	Stops a process	Permission-controlled	Cancel a stuck process
SlashCommand	Invoke a user-defined slash command	Depends on command	Inherits the command's tools	Reuse a saved workflow
EnterPlanMode	Enter plan mode mid-session to think before acting	Switches mode	None	Plan mode workflow
ExitPlanMode	Leave plan mode after presenting a plan	Switches mode	None	Plan mode workflow
Skill	Invoke a registered skill	Depends on the skill	Inherits skill tools	Domain-specific helpers

Tools surfaced by MCP servers extend this list dynamically and are addressed in Section 7.

3.2 Plan Mode

Plan mode is the read-only mode that Claude Code uses to think through a multi-step change before any file is touched. It is entered by pressing Shift+Tab twice (cycling through Default and Auto-Accept), by launching the CLI with --permission-mode plan, or by pinning it as the session default with permissions.defaultMode: "plan" in settings.json.

Aspect	Behavior
Tools allowed	Read, Glob, Grep, WebFetch, WebSearch, Task (read-only), TodoWrite
Tools blocked	Edit, Write, NotebookEdit, Bash (any command that mutates)
Exit	ExitPlanMode tool presents the plan; user approves or rejects
Persistence	The plan is held in conversation context; it is not written to disk
Use case	Large refactors, ambiguous tasks, anything reversible only with effort

The full operational rationale is in the companion harness and environment article. The point of including plan mode here is that it is an officially supported mode rather than a workflow convention.

3.3 Subagents (Agent Tool)

Subagents are independent Claude sessions launched from the parent via the Task (a.k.a. Agent) tool. They have their own context window, their own tool list, and an optional isolation strategy. They are useful for parallelizing independent work, protecting the parent context from large search results, and giving narrowly scoped tasks a fresh start.

Aspect	Behavior
Definition	.claude/agents/<name>.md with YAML frontmatter (name, description, tools, model)
Built-in subagents	general-purpose, Explore, Plan, statusline-setup, plus channel-specific helpers
Invocation	Parent calls the Task tool with subagent_type: "<name>"
Context isolation	Yes (a subagent does not see parent transcript)
Filesystem isolation	Optional via isolation: "worktree" to spawn the subagent in a git worktree
Output	Subagent returns a single final message; intermediate steps are not visible to the parent
Permissions	Subagents respect the same settings.json permission tree as the parent

Note: Subagents cannot present interactive permission prompts to the user. If a subagent invokes a tool that matches an ask rule, the call is treated as denied. The recommended pattern is to restrict subagents to read-only tool sets (omit Edit, Write, and NotebookEdit from the frontmatter tools: list) and to defer all Edit / Write / NotebookEdit / Bash work to the parent agent that can handle approval prompts. Built-in subagents whose job is to edit files (for example, statusline-setup) are exempt because their edit scope is narrow and predictable.

3.4 Skills

Skills are reusable, named bundles of instructions, scripts, and optional sub-tools that the harness can load on demand. A skill is defined by a SKILL.md file (with frontmatter) plus any supporting files, all stored under .claude/skills/<name>/.

Aspect	Behavior
Definition	.claude/skills/<name>/SKILL.md plus supporting files in the same directory
Frontmatter	name, description, optional model, optional tool list
Activation	The harness lists available skills; Claude invokes one via the Skill tool when its description matches the user request
Scoping	User-level, project-level, or plugin-bundled
Distinction from a slash command	A skill is a richer bundle (instructions plus files plus scripts), invoked via tool call rather than a literal /name prefix
Distinction from a subagent	A skill runs in the same session and context as the parent; a subagent does not

Use a slash command when the workflow is essentially "insert this prompt template." Use a skill when there is real domain logic, structured input parameters, or shipped helper files. Use a subagent when context isolation is the point.

3.5 Output Styles

Output styles configure how Claude formats its responses (verbosity, code-comment density, prose register). They are selected via the /config settings interface or by setting outputStyle directly in settings.json, and ship with a small set of built-in choices alongside any user-defined styles.

Aspect	Behavior
Built-in styles	default (concise engineering register), explanatory (richer commentary alongside code), learning (teaching tone with rationale). Additional named styles may appear in newer releases — /config always shows the canonical list for your installed version
Custom styles	Defined under .claude/output-styles/<name>.md
Settings key	outputStyle: "<name>"
How to switch	/config (interactive) or edit the outputStyle setting
Scope	Per session, applied to every assistant turn

3.6 Memory (auto-memory)

Memory is the file-based personal note system that Claude Code maintains across sessions when enabled. It is intentionally a flat directory of small Markdown files indexed by a top-level MEMORY.md. The user can ask Claude to remember or forget specific items.

Aspect	Behavior
Location	~/.claude/projects/<workspace-slug>/memory/
Index	MEMORY.md (one line per entry, loaded into context)
Memory types	user, feedback, project, reference
Add	The #<text> quick-add prefix in the prompt input, or a natural-language request to save
Remove	Ask Claude to forget the relevant entry
Scope	Per workspace

Memory is for context that should persist across conversations. Anything specific to the current conversation belongs in the todo list, not memory.

3.7 Compaction

When the conversation approaches the model's context window, the harness compacts older turns into a summary so that work can continue. Compaction can be automatic (driven by the harness) or manual (via /compact).

Aspect	Behavior
Trigger	Automatic when context window pressure is high; manual via /compact
Effect	Older turns are summarized; tool transcripts are dropped
Recovery point	The summary becomes part of the new conversation prefix
User control	/compact accepts an optional instruction (for example, "focus on what changed in the auth module")
Hooks	PreCompact fires before compaction (pre-summary side effects); PostCompact fires after with an auto / manual matcher to filter by trigger

3.8 Auto-Accept and Permission Modes

Claude Code runs in one of several permission modes that change how often it prompts the user before tool execution.

Mode	Behavior	How to Enter
Default	Standard ask / allow / deny evaluation per call	Default at session start
Auto-Accept Edits	Edits proceed without prompting; other tools still respect rules	Shift+Tab (one cycle) or /permissions
Plan Mode	Read-only; no edits or shell commands	Shift+Tab (second cycle), --permission-mode plan, or permissions.defaultMode: "plan"
Bypass Permissions	All permission rules are bypassed (sandboxed environments only)	Explicit --dangerously-skip-permissions flag

Modes are session state, not persisted in settings.json (the defaultMode key sets the initial mode; the user changes it dynamically with Shift+Tab).

3.9 Status Line

The status line shows session metadata (model in use, cwd, context usage) at the bottom of the CLI. It is configured by statusLine in settings.json and can be customized to run an external script that emits the line.

Aspect	Behavior
Default	Built-in renderer (model, cwd, tokens used)
Custom	statusLine: { type: "command", command: "<path-to-script>" }
Script contract	Reads context JSON on stdin, writes a single-line status string to stdout
Setup helper	The statusline-setup built-in subagent edits settings.json for you

3.10 Background Tasks

Long-running shell commands can be backgrounded with the run_in_background flag on the Bash tool. Claude receives notifications when each task completes and can poll output without blocking the conversation.

Aspect	Behavior
Trigger	Bash tool call with run_in_background: true
Tracking	The harness assigns a shell ID and surfaces completion notifications
Read output	BashOutput tool
Cancel	KillShell tool
Use case	Dev servers, watchers, long test suites

3.11 Plugins

A plugin is a versioned bundle that can ship one or more skills, subagents, slash commands, hooks, output styles, and MCP server definitions together as a single installable unit. Plugins are the canonical way to share reusable Claude Code extensions across teams and the public marketplace.

Aspect	Behavior
What a plugin can bundle	Skills, subagents, slash commands, hooks, output styles, MCP server definitions
Install scope	User-level (~/.claude/plugins/) or project-level (<project>/.claude/plugins/)
Discovery	The /plugin slash command browses installed plugins and configured marketplaces
Naming inside Claude Code	Plugin-namespaced items appear with a plugin:name qualifier (for example, a skill becomes plugin:skill when invoked)
Updates	Managed through /plugin; the harness can pin versions per project
Trust boundary	Plugin code runs inside the harness; treat third-party plugins like any other dependency in your supply chain

Plugins compose well with the rest of the catalog: a team plugin can pin a security-review skill, a PreToolUse hook that scans for secrets, a custom statusLine renderer, and an MCP server definition for the internal API — all installed with one /plugin command.

3.12 Headless / Non-Interactive Mode

Claude Code can run as a one-shot CLI process without a TTY, which is what makes the GitHub Action, scheduled jobs, and pre-commit integrations possible. Headless mode reuses the same settings, hooks, and permission rules as the interactive CLI.

Aspect	Behavior
Invocation	claude -p "<prompt>" (alias: --print) runs the prompt non-interactively and writes the final response to stdout
Prompt source	Argument string, stdin (echo "..." | claude -p), or a file
Auth	Use apiKeyHelper in settings.json or set ANTHROPIC_API_KEY in the environment so no browser OAuth is required
Output format	--output-format text (default) or --output-format json / stream-json for machine-readable transcripts
Session continuity	--resume <id> or --continue to keep building on a prior conversation across invocations
Permission posture	Combine --permission-mode with explicit allow/deny rules in a project settings.json; avoid --dangerously-skip-permissions outside fully sandboxed CI runners
Use case	CI review jobs, code-fix bots, scripted refactors, scheduled audits

4. Configuration Reference

This section is the catalog of every settings key the harness reads, organized by file. The companion harness and environment article covers the reasoning behind each value; here only the schema lives.

4.1 The settings.json Precedence Tree

settings.json is read from multiple locations and merged. The table is ordered from lowest precedence (read first, easily overridden) to highest precedence (read last, always wins). For scalar keys, higher-precedence layers override lower ones; for arrays, layers generally concatenate. The enterprise managed layer is the absolute policy floor — it overrides every lower layer and CLI flags cannot relax it.

Order	Path	Scope	Typical Use
1 (lowest)	~/.claude/settings.json	User (all projects)	Personal defaults
2	<project>/.claude/settings.json	Project (checked into VCS)	Team defaults
3	<project>/.claude/settings.local.json	Project (gitignored)	Personal overrides per project
4	CLI flags	Single invocation	Ad-hoc overrides
5 (highest)	Managed (enterprise)	Org-wide	Policy floor that cannot be relaxed by lower layers or CLI flags

The enterprise managed file path differs by OS: /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux and WSL, and C:\Program Files\ClaudeCode\managed-settings.json on Windows. A drop-in directory (managed-settings.d/*.json) is supported on each platform; files are merged alphabetically, with later files overriding earlier ones and arrays concatenated. On macOS, the MDM plist domain com.anthropic.claudecode and on Windows the registry key HKLM\SOFTWARE\Policies\ClaudeCode provide equivalent admin-controlled configuration.

4.2 Top-Level Keys

* You can sort the table by clicking on the column name.

Key	Type	Purpose
model	string	Default model alias (for example, "claude-sonnet-4-6", "claude-opus-4-7")
permissions	object	allow, deny, ask, defaultMode, additionalDirectories
hooks	object	Per-event hook configuration (see Section 5)
env	object	Environment variables exposed to tools
apiKeyHelper	string	Path to a script that prints an API key for non-interactive auth
mcpServers	object	MCP server definitions (see Section 7)
includeCoAuthoredBy	boolean	Whether to append a Co-Authored-By: Claude line on git commits
statusLine	object	Status line renderer (see Section 3.9)
outputStyle	string	Active output style name
theme	string	Color theme for the CLI (for example, "dark", "light", "dark-daltonized", "light-daltonized")
cleanupPeriodDays	number	How long locally stored chat transcripts are retained before cleanup; baseline 30 days
autoUpdates	boolean	Whether the CLI checks for and applies updates on launch
forceLoginMethod	string	Pin auth to one of oauth, apikey (useful in shared environments)
enableAllProjectMcpServers	boolean	Auto-approve project-defined MCP servers
enabledMcpjsonServers	string[]	Explicit allow-list of project MCP server names
disabledMcpjsonServers	string[]	Explicit deny-list of project MCP server names
disableBypassPermissionsMode	string	Set to "disable" to forbid bypassPermissions mode regardless of CLI flags (typically used in managed enterprise settings)

Observability is configured through environment variables rather than top-level settings keys; see Section 4.4 for the relevant CLAUDE_CODE_ENABLE_TELEMETRY, OTEL_*, and audit-related variables. There is no enableAuditLog key in settings.json: persistent auditing is achieved either via OpenTelemetry exporters or via a PostToolUse hook that writes structured records to your own pipeline.

4.3 The permissions Block

The permissions block governs the harness's per-tool-call evaluation.

Subkey	Type	Behavior
allow	string[]	Patterns that auto-approve a tool call
deny	string[]	Patterns that hard-deny a tool call (no prompt)
ask	string[]	Patterns that always prompt, even if matched by allow
defaultMode	string	Initial mode at session start. Supported values: "default", "acceptEdits", "plan", "bypassPermissions"
additionalDirectories	string[]	Extra directories Claude may read/write outside the project root

Patterns use tool-specific syntax. For Bash, a pattern is a literal command prefix (for example, "Bash(npm test*)"). For Read, Edit, Write, a pattern is a glob path (for example, "Read(~/Documents/**)"). Evaluation order is deny → ask → allow; the strictest match wins.

The companion harness and environment article walks through worked examples of how each pattern composes with the others; the table above is the schema only.

4.4 The env Block

Environment variables defined here are exported to every tool the harness launches.

{
  "env": {
    "BASH_DEFAULT_TIMEOUT_MS": "180000",
    "BASH_MAX_TIMEOUT_MS": "600000",
    "HTTP_PROXY": "http://proxy.example.com:3128",
    "ANTHROPIC_LOG_LEVEL": "info"
  }
}

Recognized harness-level variables include ANTHROPIC_MODEL, ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL, CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, CLAUDE_CODE_ENABLE_TELEMETRY, CLAUDE_CODE_DISABLE_THINKING, CLAUDE_CODE_DISABLE_AUTO_MEMORY, CLAUDE_CODE_SKIP_PROMPT_HISTORY, CLAUDE_CODE_EFFORT_LEVEL, CLAUDE_CODE_MAX_OUTPUT_TOKENS, BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS, DISABLE_AUTOUPDATER, MCP_TIMEOUT, MAX_MCP_OUTPUT_TOKENS, plus the standard OpenTelemetry exporters (OTEL_LOGS_EXPORTER, OTEL_METRICS_EXPORTER, OTEL_LOG_TOOL_DETAILS for extended tool span attributes such as file_path and full_command).

BASH_DEFAULT_TIMEOUT_MS overrides the per-command default timeout for the Bash tool (two minutes baseline); BASH_MAX_TIMEOUT_MS caps the value Claude may request (ten minutes baseline). Setting both to the same value pins every Bash invocation to a fixed deadline.

4.5 The ~/.claude/ Directory Layout

~/.claude/ is the per-user home for everything stateful that Claude Code maintains.

~/.claude/
  settings.json              # User-level settings
  CLAUDE.md                  # User-level instructions loaded into every session
  keybindings.json           # User-level keybinding overrides
  agents/                    # User-level subagent definitions
  commands/                  # User-level slash commands
  skills/                    # User-level skills
  output-styles/             # User-level output styles
  hooks/                     # Hook scripts referenced from settings.json
  projects/<workspace>/      # Per-project state (transcripts, memory)
    memory/                  # Auto-memory files
    sessions/                # Saved session transcripts
  logs/                      # Local logs (when enabled)

The project-scoped equivalents (<project>/.claude/...) mirror this layout for everything except projects/ and logs/.

4.6 CLAUDE.md Tiers

CLAUDE.md is the file Claude reads on session start as part of its system context. It exists at three levels which are concatenated in order.

Tier	Path	Scope	When to use
User	~/.claude/CLAUDE.md	All sessions, all projects	Personal preferences that apply everywhere
Project	<project>/CLAUDE.md	All sessions in this project	Codebase-specific conventions, build commands, layout
Subdirectory	<project>/path/CLAUDE.md	Sessions whose cwd is under this path	Subsystem-specific rules

CLAUDE.md instructs Claude's behavior at conversation start. It does not enforce anything; for enforcement, use permissions and hooks.

4.7 keybindings.json

The user-level keybinding override file lives at ~/.claude/keybindings.json. It is a JSON object whose keys are action names and values are key chords. The default keybindings are documented in Section 8; only deltas need to appear in this file.

5. Hooks Catalog

Hooks are user-supplied shell commands the harness runs at fixed points in the session lifecycle. They are the primary enforcement mechanism: a hook can block a tool call, transform a prompt, log an event, or trigger external automation.

5.1 Hook Events

* You can sort the table by clicking on the column name.

Event	Fires	Receives on stdin	Can Block	Typical Use
PreToolUse	Before every tool execution	Tool name plus tool input JSON	Yes (exit 2 denies)	Guardrails, command linting, secret scanning
PostToolUse	After every tool execution	Tool name plus result JSON	No	Audit logging, formatter, post-write linting
Notification	When Claude sends a system notification	Notification text	No	Desktop notifications, Slack pings
UserPromptSubmit	When the user submits a prompt	Raw prompt text	Yes (can also modify prompt)	Inject context, redact secrets, append global rules
Stop	When the main agent finishes a response	Session summary	No	"Done" sound, deploy, run tests
SubagentStop	When a subagent returns	Subagent summary	No	Per-subagent audit
PreCompact	Before context compaction runs	Pre-compaction state	No	Persist transcripts, mark checkpoints
PostCompact	After context compaction completes	Post-compaction summary; matcher accepts auto or manual to filter trigger	No	Reload primer context, re-inject project rules, refresh todo state
SessionStart	At the very beginning of a session	Session metadata	No	Set up scratch dirs, dump environment
SessionEnd	At session exit	Session summary	No	Tear-down, archive transcripts

The events above are the documented set as of the snapshot date. New events are occasionally added between releases; check the upstream Hooks reference for the current canonical list before wiring up a new automation.

5.2 Hook Configuration Shape

Each hook event takes a list of matchers; each matcher carries one or more commands to run. The matcher syntax is event-specific (for example, PreToolUse matchers select by tool name plus an optional input pattern).

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/guard-bash.sh" }]
      },
      {
        "matcher": "Write",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/scan-secrets.sh" }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/format-on-write.sh" }]
      }
    ]
  }
}

5.3 Hook Exit Code Semantics

Exit code	Meaning
0	Allow the action; continue normally
1	Allow with a warning surfaced to Claude
2	Deny the action; the harness aborts the tool call
other	Treated as failure; behavior is event-specific

Worked examples (a PreToolUse hook that vetoes rm -rf, a PostToolUse hook that runs prettier, a UserPromptSubmit hook that prepends global rules) are in Claude Code Harness and Environment Engineering. This page only catalogs which events exist.

6. Built-in Slash Commands

Slash commands are typed shortcuts that either reach into harness state (/permissions, /model) or invoke a saved prompt template (custom commands under .claude/commands/). The table below lists the built-ins that ship with the CLI.

6.1 Session and Conversation Control

* You can sort the table by clicking on the column name.

Command	Effect
/clear	Reset the conversation; keep cwd and settings
/compact [instruction]	Manually compact the conversation, optionally biasing what is preserved
/resume	Resume a prior session (Desktop and CLI)
/continue	Continue the most recent session
/cost	Show token usage and approximate session cost
/status	Show the current model, mode, and session metadata
/help	List available slash commands

6.2 Configuration

Command	Effect
/config	Open the settings interface; covers model, output style, theme, and other top-level settings
/model	Switch the active model alias
/permissions	Inspect or edit permission rules; toggle mode
/hooks	Inspect current hook configuration
/add-dir <path>	Add a directory to additionalDirectories for this session
/memory	Inspect or edit auto-memory entries (add inline via the # prefix in the prompt input)

6.3 Tools and Extensions

Command	Effect
/mcp	List MCP servers and their connection state
/agents	List subagents (built-in and user-defined)
/skills	List installed skills (built-in and user-defined) and their availability in the current session
/plugin	Browse, install, enable, or disable plugins (see Section 3.11)
/ide	Connect the running CLI session to a detected IDE (VS Code, JetBrains) so selections and diffs flow through
/init	Initialize a project CLAUDE.md
/install-github-app	Install the Claude Code GitHub App for the current repo
/login	Re-authenticate
/logout	Sign out

6.4 Diagnostics

Command	Effect
/doctor	Diagnose and verify the Claude Code installation (auth, network, installer integrity)
/bug	File a bug report against the CLI
/release-notes	Show release notes for the installed version
/terminal-setup	Install or refresh shell integration (key bindings, terminal hints)
/migrate-installer	Migrate between the native installer and the npm-based install
/upgrade	Open the upgrade page to switch to a higher plan tier

6.5 Editor and Productivity

Command	Effect
/vim	Enable vim keybindings in the prompt input
/fast	Toggle fast mode (Claude Opus with reduced latency; available on Opus 4.6 and Opus 4.7, no smaller-model fallback)
/pr-comments	Pull and review comments on a GitHub PR
/review	Review the pending changes on the current branch
/export	Export the current conversation to Markdown

6.6 Custom Slash Commands

User-defined slash commands live under .claude/commands/<name>.md (user-level under ~/.claude/commands/). The Markdown body is the prompt template; an optional YAML frontmatter block sets the description, allowed tools, and default model.

---
description: Run a security review of the staging branch
allowed-tools: Read, Grep, Glob, Bash, WebFetch
model: claude-opus-4-7
---
Audit the diff between `main` and `HEAD` for security issues. Focus on:
- Authentication / authorization changes
- Input handling boundaries
- Secrets in logs
- New dependencies
Report findings as a punch list.

Commands so defined are invoked as /<name>. The harness loads them at session start.

7. MCP Integration (Client Side)

Claude Code is an MCP client. It connects to MCP servers (separately authored tool servers) and exposes their tools, resources, and prompts to the model as if they were native. The catalog below describes the client-side knobs; it does not catalog individual MCP servers themselves (that survey is a separate snapshot).

7.1 Where MCP Servers Are Defined

Source	Path	Scope	Notes
User settings	~/.claude/settings.json mcpServers	User	Personal servers across all projects
Project settings	<project>/.claude/settings.json mcpServers	Project	Checked into VCS
Project local	<project>/.claude/settings.local.json mcpServers	Project	Per-developer overrides
Project .mcp.json	<project>/.mcp.json	Project	Project-distributed MCP servers; controlled by enabledMcpjsonServers / disabledMcpjsonServers
CLI flag	--mcp-config <file>	One session	Ad-hoc

7.2 Transport Types

* You can sort the table by clicking on the column name.

Transport	When to Use	How Defined
stdio	Local binary or script; default for most servers	command plus optional args and env
http (alias: streamable-http)	Remote MCP server over HTTP with streamable responses; preferred transport for remote servers	url, optional headers
sse	Remote server using Server-Sent Events; deprecated — existing configs continue to work but new servers should use http	url, optional headers

WebSocket is not a supported MCP transport in Claude Code. Use http (a.k.a. streamable-http) for remote servers and stdio for local processes.

7.3 MCP Server Definition Shape

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"]
    },
    "company-api": {
      "type": "streamable-http",
      "url": "https://mcp.example.com/v1",
      "headers": {
        "Authorization": "Bearer ${COMPANY_MCP_TOKEN}"
      }
    }
  }
}

Environment variables in ${VAR} form are resolved against the harness env block at connection time.

7.4 Permissions for MCP Tools

MCP-provided tools are named mcp__<server>__<tool> in the permission system. To allow a single tool, use "allow": ["mcp__filesystem__read_file"]. To allow every tool from one server, use "allow": ["mcp__filesystem"]. The same wildcards work in deny and ask.

The enableAllProjectMcpServers, enabledMcpjsonServers, and disabledMcpjsonServers keys gate which project-defined MCP servers are even attempted. They are a separate layer above the per-tool permission rules.

7.5 MCP Connection State

The /mcp slash command lists every configured server with its connection state (connected / connecting / failed) and the count of tools, resources, and prompts each one exposes. Servers that fail to connect at session start are retried in the background; the user is notified of failures only on demand.

8. Keybindings

The keybindings below are the default chords across the CLI and IDE channels. Override them by editing ~/.claude/keybindings.json for the CLI or via the standard IDE keybinding settings for the extension channels.

8.1 Prompt Input (CLI)

* You can sort the table by clicking on the column name.

Chord	Action
Enter	Submit the prompt
Shift+Enter	Insert a newline within the prompt
Up / Down	Recall previous / next prompts in history
Ctrl+R	Search prompt history
Tab	Autocomplete file paths, slash commands, or @ references
Shift+Tab	Cycle through permission modes (Default → Auto-Accept Edits → Plan → back to Default)
Esc	Interrupt the current model response
Esc Esc	Pop to an earlier turn
Ctrl+C	Cancel current operation / exit if pressed twice
Ctrl+D	Exit the CLI
@<file>	Attach a file reference (autocomplete-driven)
!<command>	Bash mode: run shell command without invoking the model
#<text>	Quick-add to memory
/<command>	Slash command

8.2 IDE Extensions (VS Code and JetBrains)

The IDE extensions expose a Claude Code panel and a small set of editor-level keybindings. The defaults vary slightly between VS Code and JetBrains, but the common actions are:

Action	VS Code (default)	JetBrains (default)
Toggle Claude Code panel	Cmd+Esc (macOS) / Ctrl+Esc (Win/Linux)	Tool window shortcut (configurable)
Send current selection to Claude	Right-click context menu	Right-click context menu
Accept inline edit	Enter (in diff panel)	Enter (in diff panel)
Reject inline edit	Esc	Esc
Open the active prompt input	Panel-specific input area	Panel-specific input area

Both extensions read the same settings.json tree as the CLI, so permissions, hooks, and mcpServers apply uniformly.

8.3 Desktop App

The Desktop app uses the standard host OS shortcuts (Cmd/Ctrl+N for new project, Cmd/Ctrl+, for settings, etc.). The session input area mirrors the CLI's prompt input keybindings above.

9. Recent Additions

Significant additions visible in the last three months (rolling window ending 2026-05). Each row links to the documentation or announcement post.

* You can sort the table by clicking on the column name.

Date	Area	Addition
2026-05	Subagents	Worktree isolation for the Task tool (isolation: "worktree")
2026-05	Skills	Skill packs distributable as plugins, loaded via /skills
2026-05	Hooks	SessionEnd event for archive and audit on session exit; complements the existing SessionStart, PreCompact, PostCompact, and Stop events
2026-05	CLI	/fast toggle for low-latency Claude Opus, supported on Opus 4.6 and Opus 4.7 without falling back to a smaller model
2026-05	Models	Claude Opus 4.7 (claude-opus-4-7) as default for plan-mode reasoning
2026-05	MCP	streamable-http recommended as the default remote transport
2026-05	IDE	Native selection context bridging in JetBrains plugin
2026-05	Web	Conversation share links on claude.ai/code

Items in this list age out of the next refresh once they are eight weeks old.

10. Recent Deprecations

Items that the documentation or release notes have marked for removal. Each is paired with its replacement. Entries remain in this section for one full refresh cycle after the announced removal date.

* You can sort the table by clicking on the column name.

Area	Deprecated	Replacement	Status
MCP transports	sse (older Server-Sent Events transport, deprecated)	streamable-http (alias: http)	Existing sse configs continue to work for one release cycle; new MCP servers should be configured with streamable-http
Settings	Older <project>/.mcp.json auto-trust behavior	Explicit allow-list via enabledMcpjsonServers	Behavior changed; legacy auto-trust is no longer the default
Slash commands	Dedicated /output_style and /output-style commands	/config (Settings interface, "Output style" section)	Output styles are now switched through the unified /config command rather than a dedicated slash command; the outputStyle key in settings.json remains the persistent form
Hooks	Single-string command shorthand for hook arrays	Explicit { "type": "command", "command": "..." } object	Both forms accepted in the current release; explicit object preferred

Items that have been removed entirely (no current alias) are not listed here; consult the upstream changelog for the full purge list.

11. Frequently Asked Questions

Short, direct answers to the questions that come up most often when teams adopt Claude Code. The questions are phrased to match how AI search engines retrieve Q and A blocks.

Q1. Through which channels can I use Claude Code as of 2026?

Claude Code is available as a CLI, a VS Code extension, a JetBrains plugin, a Desktop app for macOS and Windows, a Web surface at claude.ai/code, an embeddable Claude Agent SDK for TypeScript and Python, a GitHub Action, and a GitHub App. The CLI is the reference surface; every other channel mirrors a subset of its tools. The Web surface is the only channel that does not touch your local file system.

Q2. What is the difference between a subagent, a skill, and a slash command?

A slash command is a prompt template invoked as /<name>; it inserts text into the conversation. A skill is a named bundle of instructions plus optional helper files invoked via the Skill tool; it carries domain logic and parameterized inputs. A subagent is a separate Claude session launched via the Task tool; it has its own context window and is the right choice when context isolation or parallelism is the point.

Q3. Which hook event runs before a tool executes, and can it block the call?

PreToolUse runs before every tool execution. It receives the tool name and tool input on stdin. Exit code 2 from the hook denies the call; exit code 0 allows it; exit code 1 allows with a warning surfaced to Claude. This is the recommended location for guardrails (vetoing dangerous Bash patterns, scanning Write content for secrets, etc.).

Q4. Where does Claude Code read settings from, and which file wins?

Claude Code reads from five layers and merges them from lowest to highest precedence: user ~/.claude/settings.json, project <project>/.claude/settings.json, project <project>/.claude/settings.local.json, CLI flags, then the enterprise managed settings file. Higher-precedence layers override lower ones for scalar keys; arrays generally concatenate. The enterprise managed layer is the absolute policy floor — CLI flags and lower layers cannot relax it. For permissions, the strictest match wins inside any single layer (deny beats ask beats allow).

Q5. How do I add a custom MCP server to a single project without exposing it to other projects?

Define it in <project>/.claude/settings.json under mcpServers (or in <project>/.mcp.json and add the server name to enabledMcpjsonServers). For credentials, reference an environment variable in the headers block and inject the variable via env or a wrapper script. Use /mcp to verify the server connected before relying on it.

Q6. What is the difference between /compact and /clear?

/clear resets the conversation to an empty state, keeping cwd and settings. /compact summarizes the conversation so far and continues from that summary; older tool transcripts are dropped but the conceptual thread is preserved. Use /compact when you are running into context window pressure but the work is not yet done; use /clear when starting a fresh task.

Q7. How do I make a hook script that always runs after Claude writes a file?

Register a PostToolUse hook with a matcher of "Write|Edit". The hook script receives the tool name and result JSON on stdin. Use the path it reports (tool_input.file_path) to format, lint, or commit the file. Worked examples are in Claude Code Harness and Environment Engineering.

Q8. What is Shift+Tab for?

Shift+Tab cycles through the three permission modes: Default (prompt per call), Auto-Accept Edits (file edits proceed without prompting; other tools still respect rules), and Plan Mode (read-only; no edits or shell). The current mode is shown in the status line. The companion getting-started article walks through when to use each.

Q9. Can I run Claude Code without an interactive terminal, for example in CI?

Yes. The CLI accepts a non-interactive flag and reads prompts from stdin or a file; the GitHub Action wraps this for pull-request review. For API-key authentication in unattended environments, point apiKeyHelper at a script that retrieves the key from a secret manager rather than committing it to disk.

Q10. How do I see exactly what Claude Code is doing in a session?

/status shows the model and mode. /cost shows token usage. /mcp shows MCP connection state. For full transcripts and tool invocations, enable OpenTelemetry by setting CLAUDE_CODE_ENABLE_TELEMETRY=1 together with the standard OTel exporters (OTEL_LOGS_EXPORTER, OTEL_METRICS_EXPORTER) and, if you need extended span attributes such as file_path and full_command, OTEL_LOG_TOOL_DETAILS=1. For ad-hoc auditing without a collector, register a PostToolUse hook that appends structured events to your own pipeline.

12. References

External documentation and adjacent internal articles. Internal links point to other pages on this site; external links open in a new tab.

12.1 Official Documentation

• Claude Code documentation home
• CLI installation and quickstart
• Settings reference
• Hooks reference
• Slash commands reference
• MCP integration
• Subagents
• Skills
• Plan mode and permission modes

12.2 Related Internal Articles

• Claude Code Getting Started - Why Knowing About Local AI Agents Changes Everything - install walkthroughs, first session, beginner pitfalls.
• Claude Code Harness and Environment Engineering: Designing the Frontline Where Local AI Agents Actually Live - operational design, permission patterns, hook examples, three reference profiles.
• Code Review Checklist and Anti-Pattern Catalog: A Reviewer's Reference for Modern and AI-Augmented Codebases - what to check when an AI-augmented workflow produced the diff under review.

This snapshot is refreshed as needed within the publication year. Last reviewed: 2026-05.

References:
Tech Blog with curated related content