探索 .claude 目录

Permissions, hooks, and configuration

Overrides global ~/.claude/settings.json. Local settings, CLI flags, and managed settings override this

Settings that Claude Code applies directly. Permissions control which commands and tools Claude can use; hooks run your scripts at specific points in a session

.Unlike CLAUDE.md, which Claude reads as guidance

these are enforced whether Claude follows them or not

• permissions: allow, deny, or prompt before Claude uses specific tools or commands
• hooks: run your own scripts on events like before a tool call or after a file edit
• statusLine: customize the line shown at the bottom while Claude works
• model: pick a default model for this project
• env: environment variables set in every session
• outputStyle: select a custom system-prompt style from output-styles/

Bash permission patterns support wildcards: Bash(npm test *) matches any command starting with npm test

Array settings like permissions.allow combine across all scopes; scalar settings like model use the most specific value

{
    "permissions": {
        "allow": [
            "Bash(npm test *)",
            "Bash(npm run *)"
        ],
        "deny": [
            "Bash(rm -rf *)"
        ]
    },
    "hooks": {
        "PostToolUse": [{
            "matcher": "Edit|Write",
            "hooks": [{
                "type": "command",
                "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
            }]
        }]
    }
}

This example allows npm test and npm run commands without prompting, blocks rm -rf, and runs Prettier on files after Claude edits or writes them

Your personal settings overrides for this project

Highest of the user-editable settings files

CLI flags and managed settings still take precedence

Personal settings that take precedence over the project defaults. Same JSON format as settings.json, but not committed. Use this when you need different permissions or defaults than the team config.

Same schema as settings.json. Array settings like permissions.allow combine across scopes; scalar settings like model use the local value

Claude Code adds this file to ~/.config/git/ignore the first time it writes one. If you use a custom core.excludesFile, add the pattern there too. To share the ignore rule with your team, also add it to the project .gitignore

{
    "permissions": {
        "allow": [
            "Bash(docker *)"
        ]
    }
}

This example adds Docker permissions on top of whatever the team settings.json allows

Topic-scoped instructions, optionally gated by file paths

Rules without paths: load at session start

Rules with paths: load when a matching file enters context

Project instructions split into topic files that can load conditionally based on file paths. A rule without paths: frontmatter loads at session start like CLAUDE.md; a rule with paths: loads only when Claude reads a matching file.

Like CLAUDE.md, rules are guidance Claude reads, not configuration Claude Code enforces. For guaranteed behavior use hooks or permissions

Use paths: frontmatter with globs to scope rules to directories or file types

Subdirectories work: .claude/rules/frontend/react.md is discovered automatically

When CLAUDE.md approaches 200 lines, start splitting into rules

Reusable prompts you or Claude invoke by name

Invoked with /skill-name or when Claude matches the task to a skill

Each skill is a folder with a SKILL.md file plus any supporting files it needs

• By default, both you and Claude can invoke a skill
• Use frontmatter to control that:
  • disable-model-invocation: true for user-only workflows like /deploy
  • user-invocable: false to hide from the / menu while Claude can still invoke it

Skills accept arguments: /deploy staging passes "staging" as $ARGUMENTS. Use $0, $1, and so on for positional access

The description frontmatter determines when Claude auto-invokes the skill

Bundle reference docs alongside SKILL.md. Claude knows the skill directory path and can read supporting files when you mention them

Commands and skills are now the same mechanism. For new workflows, use skills/ instead: same /name invocation, plus you can bundle supporting files

User types /command-name

A file at commands/deploy.md creates /deploy the same way a skill at skills/deploy/SKILL.md does, and both can be auto-invoked by Claude. Skills use a directory with SKILL.md, letting you bundle reference docs, templates, or scripts alongside the prompt

Use $ARGUMENTS in the file to accept parameters: /fix-issue 123

If a skill and command share a name, the skill takes precedence

New commands should usually be skills instead; commands remain supported

Project-scoped output styles, if your team shares any

Applied at session start when selected via the outputStyle setting

Output styles are usually personal, so most live in ~/.claude/output-styles/. Put one here if your team shares a style, like a review mode everyone uses

See the Global tab for the full explanation and example

Specialized subagents with their own context window

Runs in its own context window when you or Claude invoke it

Each markdown file defines a subagent with its own system prompt, tool access, and optionally its own model

• Subagents run in a fresh context window, keeping the main conversation clean
• Useful for parallel work or isolated tasks

Each agent gets a fresh context window, separate from your main session

Restrict tool access per agent with the tools: frontmatter field

Type @ and pick an agent from the autocomplete to delegate directly

Dynamic workflow scripts that orchestrate many subagents

Loaded at startup; each file becomes a /<name> command

Each .js file is a dynamic workflow: a script the runtime executes to spawn and coordinate many subagents

• Workflows are written by Claude and saved here from /workflows rather than authored from scratch

Save a run from /workflows with s to create one of these

A project workflow takes precedence over a personal one in ~/.claude/workflows/ with the same name

Subagent persistent memory, separate from your main session auto memory

First 200 lines (capped at 25KB) of MEMORY.md loaded into the subagent system prompt when it runs

Subagents with memory: project in their frontmatter get a dedicated memory directory here

.This is distinct from your main session auto memory at ~/.claude/projects/

each subagent reads and writes its own MEMORY.md, not yours

Only created for subagents that set the memory: frontmatter field

This directory holds project-scoped subagent memory, meant to be shared with your team. To keep memory out of version control use memory: local, which writes to .claude/agent-memory-local/ instead. For cross-project memory use memory: user, which writes to ~/.claude/agent-memory/

The main session auto memory is a different feature; see ~/.claude/projects/ in the Global tab

Personal preferences across every project

Loaded at the start of every session, in every project

Your global instruction file. Loaded alongside the project CLAUDE.md at session start, so both are in context together

• When instructions conflict, project-level instructions take priority
• Keep this to preferences that apply everywhere: response style, commit format, personal conventions

# Global preferences

- Keep explanations concise
- Use conventional commit format
- Show the terminal command to verify changes
- Prefer composition over inheritance

Keep it short since it loads into context for every project, alongside that project's own CLAUDE.md

Good for response style, commit format, and personal conventions

Default settings for all projects

Your defaults. Project and local settings.json override any keys you also set there

Same keys as project settings.json:

• permissions
• hooks
• model
• environment variables
• and the rest

Put settings here that you want in every project, like permissions you always allow

a preferred model, or a notification hook that runs regardless of which project you're in

{
    "permissions": {
        "allow": [
            "Bash(git log *)",
            "Bash(git diff *)"
        ]
    }
}

Settings follow a precedence order: project settings.json overrides any matching keys you set here

This is different from CLAUDE.md, where global and project files are both loaded into context rather than merged key by key

Custom keyboard shortcuts

Read at session start and hot-reloaded when you edit the file

Rebind keyboard shortcuts in the interactive CLI. Run /keybindings to create or open this file with a schema reference

Ctrl+C, Ctrl+D, Ctrl+M, and Caps Lock are reserved and cannot be rebound

{
    "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
    "$docs": "https://code.claude.com/docs/en/keybindings",
    "bindings": [
        {
            "context": "Chat",
            "bindings": {
                "ctrl+e": "chat:externalEditor",
                "ctrl+u": null
            }
        }
    ]
}

This example binds Ctrl+E to open your external editor and unbinds Ctrl+U by setting it to null

The context field scopes bindings to a specific part of the CLI, here the main chat input

Custom color themes

Read at session start and hot-reloaded when files change. Listed in /theme

Each .json file defines a custom color theme: a built-in base preset plus an overrides map of color tokens.

• Create one interactively with /theme or write the JSON by hand
• Selecting a custom theme stores custom:<slug> as your theme preference

{
    "name": "Dracula",
    "base": "dark",
    "overrides": {
        "claude": "#bd93f9",
        "error": "#ff5555",
        "success": "#50fa7b"
    }
}

Auto memory: Claude's notes to itself, per project

MEMORY.md loaded at session start; topic files read on demand

Auto memory lets Claude accumulate knowledge across sessions without you writing anything

• Claude saves notes as it works: build commands, debugging insights, architecture notes
• Each project gets its own memory directory keyed by the repository path

On by default. Toggle with /memory or autoMemoryEnabled in settings

MEMORY.md is the index loaded each session. The first 200 lines, or 25KB, whichever comes first, are read

Topic files like debugging.md are read on demand, not at startup

These are plain markdown. Edit or delete them anytime

User-level rules that apply to every project

Rules without paths: load at session start

Rules with paths: load when a matching file enters context

Same as project .claude/rules/ but applies everywhere

Use this for conventions you want across all your work

like personal code style or commit message format

Personal skills available in every project

Invoked with /skill-name in any project

Skills you built for yourself that work everywhere

Same structure as project skills: each is a folder with SKILL.md

scoped to your user account instead of a single project

Personal single-file commands available in every project

User types /command-name in any project

Same as project commands/ but scoped to your user account. Each markdown file becomes a command available everywhere

Custom system-prompt sections that adjust how Claude works

Applied at session start when selected via the outputStyle setting

Each markdown file defines an output style: a section appended to the system prompt that, by default, also drops the built-in software-engineering task instructions

Use this to adapt Claude Code for uses beyond coding, or to add teaching or review modes

Select a built-in or custom style with /config or the outputStyle key in settings. Styles here are available in every project; project-level styles with the same name take precedence.

Built-in styles Explanatory and Learning are included with Claude Code; custom styles go here

Set keep-coding-instructions: true in frontmatter to keep the default task instructions alongside your additions

Changes take effect on the next session since the system prompt is fixed at startup for caching

Personal subagents available in every project

Claude delegates or you @-mention in any project

Subagents defined here are available across all your projects. Same format as project agents

Personal dynamic workflows available in every project

Loaded at startup; each file becomes a /<name> command

Workflow scripts saved here are available across all your projects

A project workflow with the same name in .claude/workflows/ takes precedence

Persistent memory for subagents with memory: user

Loaded into the subagent system prompt when the subagent starts

Subagents with memory: user in their frontmatter store knowledge here that persists across all projects

For project-scoped subagent memory, see .claude/agent-memory/ instead