lacvet/AX-Copilot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit to new repository

Browse Source
This commit is contained in:
lacvet
2026-04-03 18:23:52 +09:00
commit deffb33cf9
5248 changed files with 267762 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

126
docs/claude-code-docs-main/en/concepts/how-it-works.md Normal file
View File

@@ -0,0 +1,126 @@
> ## Documentation Index
> Fetch the complete documentation index at: https://vineetagarwal-code-claude-code.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.
# How Claude Code works
> The agentic loop, context loading, tool execution model, and conversation lifecycle under the hood.
Claude Code is a terminal-based coding agent that runs a continuous agentic loop: it reads your request, reasons about what to do, calls tools, observes results, and repeats until the task is complete or it needs your input.
## The agentic loop
Every interaction follows the same fundamental cycle:
<Steps>
<Step title="User sends a message">
You type a message in the terminal (interactive mode) or pass one via `--print` / stdin (non-interactive / headless mode). The message is appended to the conversation history.
</Step>
<Step title="Context is assembled">
Before calling the model, Claude Code assembles a system prompt that includes: the current date, git status (branch, recent commits, working-tree status), any loaded CLAUDE.md memory files, and the list of available tools. This context is built once per conversation and memoized — see [`context.ts`](/concepts/memory-context).
</Step>
<Step title="Claude reasons and selects tools">
The assembled conversation is sent to the Anthropic API. The model reasons about the task and emits one or more `tool_use` blocks — each specifying a tool name and structured JSON input.
</Step>
<Step title="Permission check">
Before executing each tool call, Claude Code evaluates the current permission mode and any allow/deny rules. Depending on the mode, it either auto-approves, prompts you for confirmation, or blocks the call entirely. See [Permissions](/concepts/permissions).
</Step>
<Step title="Tool executes and returns a result">
Approved tool calls run. Results — file contents, command output, search hits — are appended to the conversation as `tool_result` blocks.
</Step>
<Step title="Loop continues">
The model receives the tool results and either calls more tools or produces a final text response. The loop repeats until no tool calls remain in a model turn.
</Step>
</Steps>
<Note>
The loop runs entirely in your terminal process. There is no remote execution server — your files, shell, and credentials never leave your machine unless a tool explicitly sends them (e.g., `WebFetch`, `WebSearch`, or an MCP server).
</Note>
## Context loading
At the start of each conversation, Claude Code builds two context blocks that are prepended to every API call:
<Tabs>
<Tab title="System context">
Assembled by `getSystemContext()` in `context.ts`. Contains:
* **Git status** — current branch, default/main branch, git username, `git status --short` output (truncated to 2 000 characters if larger), and the last 5 commits from `git log --oneline`.
* **Cache-breaking injection** — an optional ephemeral string used internally to bust the server-side prompt cache during debugging.
Git status is skipped when `CLAUDE_CODE_REMOTE=1` is set (remote/cloud mode) or when git instructions are disabled in settings.
</Tab>
<Tab title="User context">
Assembled by `getUserContext()` in `context.ts`. Contains:
* **CLAUDE.md memory** — all memory files discovered by the 4-level hierarchy (managed → user → project → local). Disabled by `CLAUDE_CODE_DISABLE_CLAUDE_MDS=1` or in bare mode without explicit `--add-dir`. See [Memory & context](/concepts/memory-context).
* **Current date** — injected as `Today's date is YYYY-MM-DD` so the model always knows the date.
</Tab>
</Tabs>
Both context blocks are **memoized** for the duration of the conversation using `lodash/memoize`. Calling `setSystemPromptInjection()` clears the caches immediately.
## Tool execution model
Claude Code does not execute tool calls autonomously by default. Each tool has a `checkPermissions` method, and the result determines what happens next:
| Permission result | What happens |
| ----------------- | ------------------------------------------------------ |
| `allow` | Tool runs immediately, result appended to conversation |
| `ask` | Claude Code pauses and renders a confirmation dialog |
| `deny` | Tool call is rejected; Claude receives an error result |
The permission behavior is controlled by the active [permission mode](/concepts/permissions) and any configured allow/deny rules. In `bypassPermissions` mode all checks are skipped. In `acceptEdits` mode file-edit tools are auto-approved but bash commands still prompt.
Tool calls that are safe and read-only (e.g., `Read`, `Glob`, `Grep`) are generally auto-approved across all modes.
## Interactive vs. non-interactive (task) mode
<CardGroup cols={2}>
<Card title="Interactive (REPL) mode" icon="terminal">
The default experience. Claude Code renders a live terminal UI using React/Ink. You see streaming output, tool-use confirmations, and spinner animations as the agent works. Messages persist across the session until you exit.
</Card>
<Card title="Non-interactive / print mode" icon="file-code">
Activated with `--print` or by piping stdin. No UI is rendered. Output is written to stdout so it can be captured by scripts or CI pipelines. Useful for one-shot automation tasks.
</Card>
</CardGroup>
### Sub-agents (Task tool)
Claude can spawn sub-agents via the `Task` tool (`AgentTool`). Each sub-agent runs its own nested agentic loop with an isolated conversation and, optionally, a restricted tool set. Sub-agents can run locally (in-process) or on remote compute. Results are returned to the parent agent when the sub-agent completes. See [Tools](/concepts/tools) for details.
## Conversation storage and resumption
Conversations are stored as JSON transcript files on disk (in `~/.claude/` by default). Each conversation has a unique session ID. You can resume a previous conversation with `--resume <session-id>` or pick from the list with `--resume` alone.
When a conversation is resumed:
* The full message history is loaded from disk.
* Memory files are re-discovered and may differ from when the conversation was first started.
* The permission mode resets to the configured default unless it was persisted in the session.
<Tip>
Long conversations are periodically **compacted** — the oldest messages are summarised to keep the context window manageable. The full raw transcript is always preserved on disk; compaction only affects what is sent to the API.
</Tip>
## The query engine
Under the hood, each "turn" in the agentic loop is driven by a **query** — a call to `query.ts` that sends the current message list to the Anthropic API and streams back the response. The query engine handles:
* Streaming token output to the terminal in real time.
* Dispatching `tool_use` blocks to the appropriate tool handlers.
* Enforcing per-turn token and tool-call budgets.
* Collecting tool results and appending them before the next model call.
* Triggering compaction when the context window fills up.
Each tool has a `maxResultSizeChars` property. When a result exceeds this limit the content is saved to a temporary file and the model receives a preview with the file path, preventing context-window overflow from large outputs.
Built with [Mintlify](https://mintlify.com).

206
docs/claude-code-docs-main/en/concepts/memory-context.md Normal file
View File

@@ -0,0 +1,206 @@
> ## Documentation Index
> Fetch the complete documentation index at: https://vineetagarwal-code-claude-code.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Memory and context (CLAUDE.md)
> How Claude Code discovers, loads, and prioritises CLAUDE.md memory files to give Claude persistent, project-aware instructions.
Claude Code supports a layered memory system based on plain Markdown files. By writing instructions into `CLAUDE.md` files at different levels of your filesystem, you can customise Claude's behaviour globally, per-project, or per-user — and keep some instructions private while committing others to source control.
## The 4-level memory hierarchy
Memory files are loaded in the following order (from lowest to highest priority). Files loaded **later** take precedence because the model pays more attention to instructions that appear later in the context window.
<Steps>
<Step title="Managed memory (lowest priority)">
**Path:** `/etc/claude-code/CLAUDE.md` (or the platform equivalent configured by your organisation)
System-wide instructions set by an administrator or deployment tool. Applies to all users on the machine. Also supports a `rules/` subdirectory at `managed claude rules dir`. Cannot be overridden by user or project files when enforced via policy settings.
</Step>
<Step title="User memory">
**Path:** `~/.claude/CLAUDE.md` and `~/.claude/rules/*.md`
Your private global instructions that apply to every project. A good place for personal preferences like preferred code style, default language, or your git username. This file is never committed to any repository.
</Step>
<Step title="Project memory">
**Paths (checked in each ancestor directory, from root down to CWD):**
* `CLAUDE.md`
* `.claude/CLAUDE.md`
* `.claude/rules/*.md`
Instructions checked into the codebase and shared with the whole team. Ideal for project conventions, architecture notes, testing commands, and anything that every contributor should follow. Committed to source control.
</Step>
<Step title="Local memory (highest priority)">
**Path:** `CLAUDE.local.md` (checked in each ancestor directory)
Private project-specific overrides. This file should be added to `.gitignore`. Use it for personal workflow preferences that apply only to this project — local environment paths, personal shortcuts, or instructions you don't want to share.
</Step>
</Steps>
<Info>
Files closer to the current working directory are loaded **later** and therefore have **higher priority**. A `CLAUDE.md` in your project root outweighs one in a parent directory.
</Info>
## File discovery algorithm
When Claude Code starts, it walks the filesystem from the current working directory **up to the filesystem root**, collecting memory files at each level. The walk is performed by `getMemoryFiles()` in `utils/claudemd.ts`.
The discovery order ensures lower-priority files appear first in the assembled context:
1. Managed files are loaded first.
2. User files are loaded next.
3. Project and local files are loaded by iterating the path from the **root downward to CWD** — so ancestor directories come before child directories.
<Note>
The full list of discovered files is memoised for the duration of the conversation. Use `/memory` to open the memory editor and force a reload, or restart the session to pick up changes made outside Claude Code.
</Note>
## The `@include` directive
Memory files can reference other files using `@` notation. The referenced file is inserted into the context as a separate entry before the including file.
```markdown theme={null}
# My project CLAUDE.md
@./docs/architecture.md
@./docs/conventions/typescript.md
Always run `bun test` before committing.
```
**Supported path forms:**
| Syntax | Resolves to |
| ------------------ | ------------------------------------------------- |
| `@filename` | Relative path from the including file's directory |
| `@./relative/path` | Explicit relative path |
| `@~/home/path` | Path relative to the user's home directory |
| `@/absolute/path` | Absolute path |
**Rules:**
* `@include` paths inside fenced code blocks and inline code spans are **ignored** — only plain text nodes are processed.
* Circular references are detected and skipped.
* Non-existent files are silently ignored.
* Maximum include depth is **5 levels**.
* Only text-based file types are included (`.md`, `.ts`, `.py`, `.json`, etc.). Binary files such as images and PDFs are skipped.
<Warning>
By default, `@include` paths that point outside the current project directory require explicit approval. Claude Code will display a warning and ask for confirmation the first time an external include is detected.
</Warning>
## `.claude/rules/*.md` — granular rule files
Instead of putting everything in one large `CLAUDE.md`, you can split instructions across multiple Markdown files inside `.claude/rules/`:
```
my-project/
├── CLAUDE.md
└── .claude/
└── rules/
├── testing.md
├── typescript-style.md
└── git-workflow.md
```
All `.md` files in `.claude/rules/` (and subdirectories) are loaded automatically for the project and user memory levels. Rules files also support **path-scoped frontmatter**:
```markdown theme={null}
---
paths:
- "src/api/**"
- "src/services/**"
---
Always use dependency injection. Never import concrete implementations directly.
```
When `paths` is set, the rule file is only injected into context when Claude is working on a file that matches one of the glob patterns. This keeps context lean for large projects.
## Maximum file size
The recommended maximum for any single memory file is **40 000 characters** (`MAX_MEMORY_CHARACTER_COUNT`). Files that exceed this limit are flagged, and Claude may not read the full content. Keep memory files focused and concise.
## How memory affects Claude's behaviour
When memory files are loaded, they are assembled into a single context block prefixed with:
> *"Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written."*
This means instructions in CLAUDE.md files take precedence over Claude's built-in defaults. Use this to enforce project conventions, restrict certain operations, or inject domain knowledge.
## When to use each level
<AccordionGroup>
<Accordion title="Use managed memory for…">
Organisation-wide policies, security guardrails, or deployment-specific configuration that every user on a machine must follow. Managed by system administrators, not individual developers.
</Accordion>
<Accordion title="Use user memory (~/.claude/CLAUDE.md) for…">
Personal preferences that apply across all projects: your preferred language for responses, commit message style, editor shortcuts, or personal aliases. This is private and never committed.
</Accordion>
<Accordion title="Use project memory (CLAUDE.md) for…">
Project conventions shared with your team: how to run tests, build commands, architecture decisions, naming conventions, PR checklist items, or links to internal documentation. Commit this file.
</Accordion>
<Accordion title="Use local memory (CLAUDE.local.md) for…">
Your personal overrides for a specific project: local environment paths, personal debugging notes, or workflow preferences that differ from the team defaults. Add this to `.gitignore`.
</Accordion>
</AccordionGroup>
## Example CLAUDE.md
```markdown theme={null}
# My Project
## Commands
- Build: `bun run build`
- Test: `bun test`
- Lint: `bun run lint`
- Type check: `bun run typecheck`
## Architecture
This is a monorepo. Core logic lives in `packages/core`. The CLI entrypoint is `src/index.ts`.
## Conventions
- Use `zod/v4` for all schema validation.
- Never use `any` — prefer `unknown` with a type guard.
- All async functions must handle errors explicitly; never swallow exceptions.
- Tests go in `__tests__/` next to the source file they test.
## Git
- Branch names: `feat/<ticket>-short-description`
- Always run `bun test && bun run typecheck` before committing.
- Do not include `console.log` statements in committed code.
@./docs/api-conventions.md
```
## The `/memory` command
Run `/memory` inside the Claude Code REPL to open the memory file editor. It shows you which memory files are currently loaded, lets you edit them directly, and reloads the context when you save.
<Tip>
You can ask Claude directly: *"Add a rule to CLAUDE.md that we always use 2-space indentation."* Claude will locate the appropriate memory file and write the instruction for you.
</Tip>
## Disabling memory loading
| Method | Effect |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `CLAUDE_CODE_DISABLE_CLAUDE_MDS=1` | Disables all memory file loading entirely |
| `--bare` flag | Skips auto-discovery of memory files from the CWD walk; only loads files from explicitly provided `--add-dir` directories |
| `claudeMdExcludes` setting | Glob patterns of memory file paths to skip (e.g., to exclude a noisy ancestor `CLAUDE.md`) |
Built with [Mintlify](https://mintlify.com).

222
docs/claude-code-docs-main/en/concepts/permissions.md Normal file
View File

@@ -0,0 +1,222 @@
> ## Documentation Index
> Fetch the complete documentation index at: https://vineetagarwal-code-claude-code.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Permissions
> How Claude Code controls which operations Claude can perform automatically versus which require your explicit approval.
Claude Code runs tools on your local machine — executing shell commands, editing files, fetching URLs. The permission system gives you precise control over which operations Claude performs automatically and which require your explicit approval.
## What permissions control
Permissions apply to three categories of operations:
<CardGroup cols={3}>
<Card title="File operations" icon="file">
Reading, editing, and writing files on your local filesystem via the `Read`, `Edit`, and `Write` tools.
</Card>
<Card title="Bash commands" icon="terminal">
Any shell command executed through the `Bash` tool, including installs, builds, git operations, and arbitrary scripts.
</Card>
<Card title="MCP tool calls" icon="plug">
Tools exposed by connected MCP servers, which may include database queries, API calls, or browser automation.
</Card>
</CardGroup>
## Permission modes
The permission mode determines the default behaviour when no specific allow/deny rule matches a tool call. Set the mode once and it applies for the entire session.
<AccordionGroup>
<Accordion title="default — ask for potentially dangerous operations">
The standard mode. Claude Code evaluates each tool call and prompts you for confirmation on operations that could have side effects: running shell commands, editing files, making network requests. Read-only operations (file reads, searches) are auto-approved.
This is the recommended mode for everyday use.
</Accordion>
<Accordion title="acceptEdits — auto-approve file edits">
File edit and write operations (`Edit`, `Write`) are automatically approved without prompting. Bash commands still require confirmation.
Useful when you trust Claude to make file changes freely but still want to review shell commands.
</Accordion>
<Accordion title="plan — read-only planning mode">
Claude can read files, search the codebase, and discuss changes, but cannot execute any write or bash operations. All mutating tool calls are blocked.
Use this mode when you want Claude to analyse a problem and produce a plan before you authorise any changes. The model can exit plan mode and request permission to proceed via the `ExitPlanMode` tool.
</Accordion>
<Accordion title="bypassPermissions — skip all permission checks">
All permission checks are disabled. Every tool call is executed immediately without any confirmation prompts.
<Warning>
This mode is intended for automated, fully-scripted workflows where you have audited what Claude will do in advance. Never use `bypassPermissions` in an interactive session where Claude might take unexpected actions.
</Warning>
</Accordion>
<Accordion title="dontAsk — suppress prompts">
Similar to `bypassPermissions` but uses a slightly different internal path. Tool calls that would normally prompt are auto-approved. Intended for scripted/non-interactive scenarios.
</Accordion>
<Accordion title="auto — transcript-classifier mode (feature-gated)">
An experimental mode that uses a secondary AI classifier to evaluate each proposed tool call against the conversation transcript. The classifier decides whether the operation is within the scope of what was requested, and either auto-approves or escalates to a human prompt.
This mode is only available when the `TRANSCRIPT_CLASSIFIER` feature flag is enabled.
</Accordion>
</AccordionGroup>
## Setting the permission mode
<Tabs>
<Tab title="CLI flag">
Pass `--permission-mode` when starting Claude Code:
```bash theme={null}
claude --permission-mode acceptEdits
claude --permission-mode bypassPermissions
claude --permission-mode plan
```
</Tab>
<Tab title="/permissions command">
Change the mode mid-session without restarting:
```
/permissions
```
An interactive menu lets you select the new mode. The change takes effect for the remainder of the session.
</Tab>
<Tab title="settings.json">
Set a persistent default in your user or project settings:
```json theme={null}
{
"defaultMode": "acceptEdits"
}
```
Valid values: `"default"`, `"acceptEdits"`, `"bypassPermissions"`, `"plan"`, `"dontAsk"`.
</Tab>
</Tabs>
## Permission rules (allow/deny lists)
Beyond the global mode, you can create fine-grained rules that always allow or always deny specific tool calls — regardless of the active mode.
Rules have three components:
| Field | Description |
| ------------- | -------------------------------------------------------------------------------------- |
| `toolName` | The name of the tool the rule applies to (e.g., `"Bash"`, `"Edit"`, `"mcp__myserver"`) |
| `ruleContent` | An optional pattern that must match the tool's input (e.g., a command prefix for Bash) |
| `behavior` | `"allow"`, `"deny"`, or `"ask"` |
Rules are evaluated **before** the permission mode. If a matching rule exists, its behavior is applied immediately.
### Rule sources and persistence
Rules can originate from different sources and are stored accordingly:
| Source | Where stored | Scope |
| ----------------- | ----------------------------- | --------------------------------- |
| `userSettings` | `~/.claude/settings.json` | All projects for the current user |
| `projectSettings` | `.claude/settings.json` | All users of this project |
| `localSettings` | `.claude/settings.local.json` | Current user, this project only |
| `session` | In-memory | Current session only |
| `cliArg` | CLI flags | Current invocation only |
### Example: always allow specific git commands
```json theme={null}
{
"permissions": {
"allow": [
"Bash(git status)",
"Bash(git diff *)",
"Bash(git log *)",
"Read(*)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)"
]
}
}
```
## How bash permissions work
Bash command permission checking deserves special attention because shell commands can be complex and ambiguous.
### Pattern matching
A `Bash` permission rule with a `ruleContent` string is matched against the command using wildcard pattern matching:
* `git status` — exact match only
* `git *` — matches any `git` subcommand
* `npm run *` — matches any `npm run` script
* `*` — matches any bash command (use with extreme caution)
### Compound commands
When a bash command contains multiple sub-commands joined by `&&`, `||`, `;`, or pipes (`|`), each sub-command is checked independently. The overall permission is the most restrictive result: if any sub-command is denied, the entire compound command is blocked.
### Operator restrictions
Certain shell constructs are flagged for extra scrutiny regardless of rules:
* Output redirections (`>`, `>>`) to paths outside the project directory
* Commands that change the current directory (`cd`) to outside the working tree
* `sed -i` edit-in-place commands (handled specially to track file modifications)
### Safety checks
Regardless of the active permission mode, certain operations are always blocked or escalated:
* Commands targeting `.claude/` or `.git/` configuration directories
* Modifications to shell config files (`.bashrc`, `.zshrc`, etc.)
* Attempts to bypass path restrictions using cross-platform path tricks
<Note>
In `auto` mode (feature-gated), safety checks marked `classifierApprovable: true` are sent to the transcript classifier rather than forcing a prompt. The classifier has visibility into the full conversation context and can decide whether the operation is appropriate.
</Note>
## MCP tool permissions
MCP tools follow the same rule system as built-in tools. You can allow or deny an entire MCP server or individual tools within a server:
```json theme={null}
{
"permissions": {
"deny": [
"mcp__myserver"
],
"allow": [
"mcp__myserver__read_database"
]
}
}
```
Using `mcp__servername` as the rule (without a specific tool name) blanket-denies all tools from that server — they are filtered out of the tool list before the model even sees them.
## Safety recommendations
<Warning>
`bypassPermissions` and `dontAsk` modes remove all safeguards. Only use them in isolated environments (containers, CI sandboxes) where Claude's actions are constrained by the environment itself, not by permission prompts.
</Warning>
* **Start with `default` mode** for any interactive session.
* **Use `plan` mode** when exploring an unfamiliar codebase or designing a large change — review the plan before enabling writes.
* **Use `acceptEdits`** for coding sessions where you trust Claude to edit files freely but want to review shell commands.
* **Prefer granular allow rules** over broad mode escalation. Allowing `Bash(git *)` is safer than switching to `bypassPermissions`.
* **Scope deny rules tightly.** A blanket `Bash(*)` deny prevents Claude from running any shell command, including safe read-only operations.
* **Review project settings files** (`.claude/settings.json`) when cloning unfamiliar repositories — they may pre-configure permission rules.
Built with [Mintlify](https://mintlify.com).

208
docs/claude-code-docs-main/en/concepts/tools.md Normal file
View File

@@ -0,0 +1,208 @@
> ## Documentation Index
> Fetch the complete documentation index at: https://vineetagarwal-code-claude-code.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Tools
> Reference for every built-in tool Claude Code can use, including file operations, shell execution, web access, and sub-agent spawning.
Claude Code gives Claude a set of built-in tools it can call to interact with your machine. Each tool call is subject to the active [permission mode and rules](/concepts/permissions). Below is a reference for every tool available by default.
## File tools
<CardGroup cols={2}>
<Card title="Read" icon="file-lines">
**Read a file from the local filesystem.**
Reads up to 2 000 lines by default. Supports an `offset` and `limit` for targeted reads of large files. Returns content in `cat -n` format with line numbers.
Also supports reading images (PNG, JPG, etc.) as visual input, PDF files (up to 20 pages at a time), and Jupyter notebooks (`.ipynb`).
Read-only. Always auto-approved in `default` mode.
</Card>
<Card title="Edit" icon="file-pen">
**Perform exact string replacements in a file.**
Requires a prior `Read` call on the file in the same conversation. Replaces `old_string` with `new_string` — the match must be unique in the file. Use `replace_all: true` to rename across the entire file.
Fails if `old_string` appears more than once (unless `replace_all` is set). This precision prevents unintended edits.
</Card>
<Card title="Write" icon="file-arrow-up">
**Create a new file or completely overwrite an existing one.**
For existing files, a prior `Read` call is required in the same conversation. Prefer `Edit` for modifying existing files — `Write` sends the entire file content and is better suited for new files or full rewrites.
</Card>
<Card title="Glob" icon="folder-magnifying-glass">
**Find files by name pattern.**
Fast pattern matching that works on any codebase size. Returns matching file paths sorted by modification time (most recently modified first).
Supports patterns like `**/*.ts`, `src/**/*.test.js`, `**/CLAUDE.md`. For open-ended multi-step searches, use the `Task` tool instead.
Read-only. Always auto-approved.
</Card>
</CardGroup>
## Shell tool
<Card title="Bash" icon="terminal">
**Execute a shell command in a persistent shell session.**
Runs the command in a shell that persists across tool calls within a conversation — environment variables and working-directory changes carry over between calls. Supports a `timeout` parameter (default and max values are configurable).
Key behaviours:
* **Compound commands** (`&&`, `||`, `;`, `|`) are parsed and each sub-command is permission-checked independently.
* **Background execution** — pass `run_in_background: true` to run a long-running command without blocking. You are notified when it completes.
* **Output limits** — stdout/stderr is truncated if it exceeds the per-tool result size budget; a preview and file path are returned instead.
* **Search commands** (`find`, `grep`, `rg`) — for content search, prefer the dedicated `Grep` tool, which has optimised permissions and access.
Subject to permission prompts in `default` mode. Auto-approved in `acceptEdits` mode only for commands covered by an allow rule.
</Card>
## Search tools
<CardGroup cols={2}>
<Card title="Grep" icon="magnifying-glass">
**Search file contents using regular expressions.**
Built on ripgrep. Supports full regex syntax (`log.*Error`, `function\s+\w+`), file-type filtering (`*.ts`, `**/*.py`), and three output modes:
* `files_with_matches` (default) — returns only file paths
* `content` — returns matching lines with context
* `count` — returns match counts per file
Multiline patterns are supported with `multiline: true`.
Read-only. Always auto-approved.
</Card>
<Card title="LS" icon="list">
**List directory contents.**
Returns files and subdirectories in a structured format. Useful for exploring project structure before reading or editing files.
Read-only. Always auto-approved.
<Note>In bare-minimum mode (`CLAUDE_CODE_SIMPLE=1`) only `Bash`, `Read`, and `Edit` are available — use `ls` via `Bash` instead.</Note>
</Card>
</CardGroup>
## Web tools
<CardGroup cols={2}>
<Card title="WebFetch" icon="globe">
**Fetch a URL and extract information from it.**
Takes a URL and a prompt describing what to extract. Converts HTML to Markdown, then passes the content through a secondary model to produce a focused answer.
Features:
* HTTP URLs are automatically upgraded to HTTPS.
* Includes a 15-minute self-cleaning cache — repeated fetches of the same URL are fast.
* When a URL redirects to a different host, the tool returns the redirect URL for a follow-up request.
* For GitHub URLs, prefer the `gh` CLI via `Bash` (e.g., `gh pr view`, `gh api`).
Read-only. Prompts for approval in `default` mode.
</Card>
<Card title="WebSearch" icon="magnifying-glass-arrow-right">
**Search the web and return results.**
Returns search results with titles, snippets, and URLs formatted as Markdown links. Useful for accessing information beyond the model's training cutoff.
After answering, Claude automatically appends a `Sources:` section listing all referenced URLs.
Domain filtering is supported to include or exclude specific sites. Currently only available in the US.
Prompts for approval in `default` mode.
</Card>
</CardGroup>
## Agent and task tools
<CardGroup cols={2}>
<Card title="Task (Agent)" icon="robot">
**Spawn a sub-agent to complete a task.**
Starts a nested agentic loop in a separate context. The sub-agent has its own conversation history, its own tool set (optionally restricted), and runs to completion before returning a result to the parent agent.
Sub-agents can run:
* **Locally** — in-process, sharing the parent's filesystem and shell
* **Remotely** — on separate compute when remote agent eligibility criteria are met
Use `Task` for open-ended multi-step searches, parallel workstreams, or delegating distinct sub-problems to isolated agents.
The parent agent receives the sub-agent's final output as a tool result.
</Card>
<Card title="TodoWrite" icon="list-check">
**Create and manage a structured task list.**
Writes a list of todo items with statuses (`pending`, `in_progress`, `completed`) to a persistent panel in the terminal UI. Helps Claude track progress on complex multi-step tasks and shows you what it is working on.
Use proactively for tasks with 3 or more distinct steps. Not necessary for simple single-step requests.
Results are rendered in the todo panel, not the conversation transcript.
</Card>
</CardGroup>
## MCP tools
MCP (Model Context Protocol) servers can expose additional tools to Claude Code. Connected tools appear in the tool list alongside built-in tools and follow the same permission system.
MCP tools are named with a `mcp__` prefix:
```
mcp__<server-name>__<tool-name>
```
For example, a tool named `query` on a server named `mydb` appears as `mcp__mydb__query`.
Common MCP tool categories include:
* Database query and management tools
* Browser and web automation tools
* Cloud provider APIs (AWS, GCP, Azure)
* Issue tracker integrations (GitHub, Linear, Jira)
* Internal company tools and APIs
<Info>
MCP servers are configured in `~/.claude/mcp_servers.json` or `.claude/mcp_servers.json`. Tools from a connected server are automatically included in Claude's context once the server is running.
</Info>
To deny all tools from a specific MCP server, add a deny rule for the server prefix:
```json theme={null}
{
"permissions": {
"deny": ["mcp__untrusted-server"]
}
}
```
## Notebook tool
<Card title="NotebookEdit" icon="book">
**Edit cells in a Jupyter notebook.**
Allows Claude to insert, replace, or delete cells in a `.ipynb` file with line-level precision. Read notebooks using the standard `Read` tool, which returns all cells and their outputs.
</Card>
## Tool availability
Not all tools are available in every context. The active tool set is determined at startup and can be affected by:
* `CLAUDE_CODE_SIMPLE=1` — restricts to `Bash`, `Read`, and `Edit` only
* Permission deny rules — tools blanket-denied by a rule are removed from the tool list before the model sees them
* `isEnabled()` checks — each tool can self-disable based on environment conditions (e.g., `WebSearch` is gated by region)
* MCP server connection state — MCP tools are only available when the server is running and connected
You can inspect the active tool set with the `/tools` command in the REPL.
Built with [Mintlify](https://mintlify.com).