01Get it installed
One command. You need a Claude subscription (Pro, Max, Team, or Enterprise) or a Console account — the terminal tool is not on the free plan.
$ curl -fsSL https://claude.ai/install.sh | bash
Installs for macOS, Linux, and Windows Subsystem for Linux. It keeps itself updated in the background.
> irm https://claude.ai/install.ps1 | iex
> winget install Anthropic.ClaudeCode
Not sure which window you are in? PowerShell shows PS C:\ at the start of the line. Plain CMD shows C:\ with no PS. Installing Git for Windows first is recommended. WinGet does not auto-update — run winget upgrade Anthropic.ClaudeCode now and then.
$ brew install --cask claude-code
Homebrew installs do not auto-update. Run brew upgrade claude-code to get fixes.
Check it worked
$ claude --version
Sign in
Just start it. The first run walks you through signing in through your browser. After that your login is remembered.
$ claude
To switch accounts later, type /login inside a running session.
02Your first five minutes
The single thing to understand: Claude Code works on the folder you started it in. So step one is always "go to the folder, then start."
-
Go to your project folder
Change directory, then start$ cd ~/projects/my-app $ claude
On Mac, you can type
cdthen drag the folder from Finder into the terminal window to fill in the path. -
Ask it to look around first
Never lead with a change. Let it read before it writes.
Type this at the > and press Enter> what does this project do?
It opens the files it needs on its own. You do not have to paste code in or attach anything.
-
Ask for one small change
A first, low-risk request> add a hello world function to the main file
-
Read the diff, then approve
It shows you exactly what it wants to change and waits. Green is added, red is removed. Say yes, or say no and explain what you would rather it did.
-
Keep talking
It remembers everything in this session. You do not repeat context.
Follow-ups> now write a test for it > commit my changes with a descriptive message
-
Leave, and come back later
Exit, then pick up where you left off> /exit $ claude -c
claude -ccontinues the most recent conversation in this folder.claude -rlets you pick from a list of older ones.
The safety net: work in a folder that uses Git. Then any change Claude makes can be undone with one command, and you can see exactly what it did with git diff.
03How to ask for things
This is the whole skill. Talk to it like a capable new colleague who has never seen your project: specific about the goal, honest about the constraints, quick to correct.
Vague in, vague out
"fix the bug"
"clean up this file"
"make it better"
It has to guess which bug, which file, and what "better" means. It will guess wrong at least some of the time.
"fix the login bug where users see a blank screen after entering wrong credentials"
"split utils.js into one file per concern, keep the exports the same"
Name the symptom, the place, and what "done" looks like.
The four moves
Explore
"read the auth module and explain how sessions are stored"
Cheap, safe, and makes everything after it better.
Plan
"before changing anything, give me a plan for adding rate limiting"
Argue with the plan, not the finished code.
Do
"go ahead with step 1 and 2, stop before touching the database"
Boundaries are respected. Say them out loud.
Check
"run the tests" · "review your own change and tell me what could break"
It can run your test suite and read the failures itself.
Break big work into a numbered list
> 1. create a table for user profiles 2. add an endpoint to get and update a profile 3. build a page where users can edit their info
Two characters worth memorising
@ points at a file
Type @ and it autocompletes file paths, so you can say exactly which one you mean.
"why is @src/api/auth.ts slower than the others?"
! runs a shell command
Start a line with ! to run something yourself. The output lands in the conversation and Claude responds to it.
! npm test — then it explains the failures without you asking.
When it goes off-track: press Esc. It stops mid-thought, keeps the work done so far, and hands the conversation back to you. Redirect and carry on. Do not sit and watch it do the wrong thing.
04The four permission modes
This is the setting people wish they had known about on day one. Press Shift+Tab inside a session to cycle modes. The current mode is shown near the input.
Manual
The default. Asks before every file change.
Use while you are learning it, or in code you care deeply about.Accept edits
File edits go through without asking. It still stops for riskier things.
Use once you trust the plan and want to stop pressing yes.Plan
Read-only. It investigates and proposes, but changes nothing.
Use for anything large or unfamiliar. Genuinely the best mode.Bypass / Auto
Stops asking. Some accounts get an auto mode that runs a background safety check and blocks risky actions.
Only in a throwaway folder or a container. Not on your main machine.The habit worth building: start in Plan mode → read the plan → switch to Accept edits → let it work → check the diff with git diff.
What it can and cannot reach
- It works inside the folder you started it in. To give it a second folder, use
/add-dir ../other-project. - It asks before running commands that change things, unless you have turned that off.
- Anything it does is visible:
git diffshows every edit, and Ctrl+O shows every tool it used.
05Commands you will actually use
Two kinds. Shell commands start Claude Code from your terminal. Slash commands are typed inside a running session. Type / on its own to see everything your version has.
Starting it (from your terminal)
| Command | What it does |
|---|---|
claude | Start a normal session in the current folder |
claude "fix the build error" | Start with the first request already typed |
claude -p "explain this function" | Answer once, print it, exit. Good inside scripts |
claude -c | Continue the most recent conversation in this folder |
claude -r | Pick an older conversation from a list and resume it |
claude --version | Check which version you have |
Inside a session
| Command | What it does |
|---|---|
/help | The honest list of what your version can do. Start here |
/ | Type just the slash to browse every command and skill |
/clear | Start a fresh conversation. Use it between unrelated tasks |
/compact | Summarise the conversation to free up room, keeping the thread |
/init | Scan the project and write a starter CLAUDE.md. Run once per project |
/memory | Open and edit what Claude remembers about you and this project |
/resume | Jump to a different past conversation without leaving |
/config | Settings: theme, editor mode, notifications |
/login | Sign in again or switch accounts |
/model | Switch models, and optionally save the choice as your default for new sessions |
/effort | Set how hard it thinks before answering: low, medium, high, or max |
/cost | See what this session has spent so far |
/agents | See the subagents available to you, project and personal |
/mcp | Show connected outside services and what each is costing you in context |
/hooks | See and configure the scripts that fire automatically on events |
/permissions | Edit what is always allowed and always denied, without leaving the session |
/doctor | Diagnose your install — PATH, version, config problems |
/bug | Report a problem straight to Anthropic, with context attached |
/btw what was that file called? | Ask a side question. The answer never enters the conversation |
/add-dir ../shared-library | Let it see a second folder too |
/exit | Leave the session |
/clear versus /compact: use /clear when you finish one job and start an unrelated one. Use /compact when you are still on the same job but the conversation has got long.
A setting can outrank you: /model and /effort save your personal default for new sessions. But if a project's .claude/settings.json pins a model, that pin wins in this project once you restart — your personal default just applies everywhere else. The command's own output tells you when this happens.
06Keys that save you
Six of these matter. The rest are nice to know.
Esc
Stop Claude mid-answer. It keeps what it has done and hands control back.
Esc Esc
On an empty line, opens the rewind menu — go back to how things were earlier.
Shift+Tab
Cycle permission modes: manual, accept edits, plan.
Ctrl+C
Interrupt what is running. If nothing is running, it clears your typing; twice exits.
↑
Bring back something you typed before — including from past sessions in this folder.
Ctrl+O
Show the full transcript: every file read, every command run.
Worth knowing
| Keys | What happens |
|---|---|
| Ctrl+R | Search everything you have typed before |
| Ctrl+G | Write a long message in your normal text editor instead |
| Ctrl+V | Paste a screenshot straight in. On Windows and WSL use Alt+V |
| Ctrl+B | Send a long-running command to the background and carry on |
| Ctrl+L | Redraw the screen if the display gets garbled |
| \ then Enter | Write a second line without sending yet. Works in every terminal |
| Ctrl+D | Press twice to exit |
| ? | On an empty line, shows the shortcut panel |
Shortcuts vary a little by terminal and platform. The ? panel inside your own session is always the truth.
07Make it remember
Every session starts with a blank memory of the conversation. Two things carry across: a file you write, and notes it writes itself.
CLAUDE.md — the instructions you write
A plain markdown file in your project. It is read at the start of every session. This is where "we use pnpm, not npm" lives, so you never type it again.
> /init
It reads the project and drafts the file for you. Then edit it down — short and specific beats long and thorough.
- The commands to build, test, and run
- Conventions a newcomer would get wrong
- Things that are off-limits ("never edit generated files in
dist/") - Where the important code lives
- Anything it can read from the code itself
- A rule added in frustration after one bad session
- Whole documents pasted in — link to them instead
- Secrets, keys, or passwords. Ever
Auto memory — the notes it writes itself
As you work, Claude saves things worth keeping: build commands, debugging insights, the way you like things done. It is on by default. Run /memory to see what it has saved, edit it, or turn it off.
Reality check: instructions are guidance, not enforcement. Claude usually follows CLAUDE.md, but it is not a lock. If something must never happen, enforce it outside the conversation — a hook, a permission rule, or CI.
08When it goes wrong
Nine problems out of ten are on this page.
It changed something I did not want
Press Esc Esc to rewind. Or, if the folder uses Git, git diff to see it and git checkout -- . to throw it away.
It is confidently doing the wrong thing
Esc, then say what is wrong in one sentence. Do not restate the whole task — it still has everything you said.
Answers got vague or repetitive
The conversation is too long. /compact to keep going on the same job, or /clear to start clean.
It cannot find a file I know exists
You started it in the wrong folder. /exit, cd to the right place, start again. Or /add-dir the other folder.
It keeps asking permission for everything
Shift+Tab to accept-edits mode — once you have read and agreed with the plan.
The screen looks broken
Ctrl+L redraws it. Nothing is lost.
I do not know what a command does
/help, or just ask in plain words: "what does /compact actually do?" It knows its own documentation.
Install failed
Check you are in the right shell — PowerShell shows PS C:\, plain CMD does not. Otherwise try a different install method from section 1.
claude: command not found
The installer added it to your PATH, but your terminal has not reloaded. Open a new terminal window. Still nothing? Run the install command again from section 1.
Something in the install or config feels broken
claude doctor checks your install, your PATH, and your config for problems and tells you what is wrong in plain language.
The one rule that prevents most disasters: use Git, and commit before you turn Claude loose on anything big. Then the worst case is one command to undo.
09Cheat card
Print this and put it next to the keyboard.
cd into the folder → claude
Ask it to look around before it changes anything
Shift+Tab → plan mode for anything big
Read the diff before you say yes
/clear when you move to a different job
Esc — stop it
Esc Esc — rewind
Shift+Tab — change mode
↑ — reuse what you typed
Ctrl+O — see what it did
Ctrl+C twice — get out
/help — what your version can do
/init — teach it this project
/compact — free up room, same job
/clear — fresh start
claude -c — carry on from yesterday
/exit — leave
Name the symptom, not just "it's broken"
Say where to look, and where not to touch
Ask for a plan before a big change
Number your steps when there are several
Correct in one sentence, do not start over
If you remember one thing: talk to it like a sharp colleague who is new to your project. Say what you want and what "done" looks like. Everything else is detail.
10Past the basics
Everything in sections 1–9 is Claude Code out of the box. This section is the extension layer: the parts that turn it from a smart assistant into a system you have shaped. Read it once end to end, then add one piece at a time.
Do not install all of this on day one. Each feature has a moment where it becomes obviously necessary. The table at the bottom of this section tells you when that moment has arrived for each one.
The whole map, on one screen
| Feature | What it actually is | Reach for it when |
|---|---|---|
| CLAUDE.md | A file loaded into every session | Claude gets a convention wrong twice |
| Rules | CLAUDE.md split into files that load only for matching paths | CLAUDE.md is over ~200 lines |
| Skills | Markdown Claude loads on demand, or you trigger with /name | You keep pasting the same playbook |
| Subagents | A worker with its own context window that returns only a summary | A side task floods your conversation |
| Agent teams | Several independent sessions that message each other | Parallel work that needs to be discussed, not just split |
| Hooks | Your script, fired automatically at a lifecycle event | Something must happen every single time |
| MCP | A standard way to plug in outside services and their tools | You keep copying data from a tab Claude cannot see |
| Worktrees | An isolated second checkout of the repo, on its own branch | You want to experiment without touching your working copy |
| Scheduling | A repeating loop, or a cloud agent on a cron schedule | Something should happen on a timer, with or without you |
| Plugins | All of the above, bundled and installable in one command | A second repo needs the same setup |
Skills are the most flexible of these, and the one most people underuse. Hooks are the only one that gives you a guarantee.
Skills — teach it a workflow once
A skill is a markdown file containing knowledge or a procedure. Claude can load it automatically when your task matches its description, or you can invoke it directly with /name. Custom slash commands and skills are now the same thing.
--- name: deploy description: Ship to staging. Use when asked to deploy or release. allowed-tools: Read, Bash, Grep --- # Deploy to staging 1. Confirm the branch is clean and tests pass. 2. Run `pnpm build` and stop if it fails. 3. Push to the staging remote. 4. Tail the logs for 30 seconds and report anything unusual. Never deploy on a Friday after 16:00 without asking me first.
Two kinds of skill
Reference — knowledge Claude pulls in when relevant: your API style guide, your database schema, your house conventions for tests.
Action — a workflow you fire off: /deploy, /release, /audit.
Useful frontmatter
disable-model-invocation: true hides it from Claude until you type it. Use this for anything with side effects, and it costs zero context until used.
context: fork runs the skill in an isolated context instead of your main conversation.
Claude Code also ships with bundled skills such as /code-review, /batch, and /debug. Type / to see which ones your version has. Skills live in .claude/skills/ for a project or ~/.claude/skills/ for you personally.
Subagents — send someone else to read the boring files
A subagent is a separate Claude with its own fresh context window. It does a job and reports back a summary. The forty files it read never enter your conversation. This is the main tool for keeping a long session sharp.
> create a subagent that reviews my changes for security problems
--- name: security-reviewer description: Reviews changed code for security issues. Use after edits. tools: Read, Grep, Glob, Bash model: sonnet --- You are a careful security reviewer. 1. Run `git diff` to see what changed. 2. Look for injection, secrets in code, and missing authorization checks. 3. Report findings as Critical / Warning / Suggestion. Nothing else.
- Leave
toolsout and it inherits everything. Narrow it when you want a worker that cannot write. model: haikufor cheap searching,sonnetfor most work,opusfor hard judgement.- Other fields worth knowing:
skills(preload knowledge into it),maxTurns,permissionMode,disallowedTools. - Three subagents are built in: Explore (read-only, fast), Plan (gathers context for plan mode), and general-purpose. Claude routes to these on its own.
- Project agents live in
.claude/agents/; personal ones in~/.claude/agents/.
In recent versions /agents no longer opens a creation wizard — it points you at the files. Asking Claude to write the agent is the fastest path.
Agent teams — several sessions that talk to each other
A subagent reports to you. A team is different: independent sessions that message each other directly and share a task list. Good for research with competing hypotheses, parallel review, or a feature where each teammate owns a separate piece.
One worker, isolated, summary comes back to you. Cheaper.
Use when only the result matters.
Peers that challenge each other and coordinate. Each is a full session, so the cost is real.
Use when the work needs discussion.
Agent teams are experimental and switched off by default. If you just want two of your own sessions to pass notes, look at cross-session messaging instead — type @ and it will suggest your other live sessions.
Hooks — the only thing here that is a guarantee
Everything you write in CLAUDE.md is a request. Claude usually honours it. A hook is different: your script runs at a lifecycle event whether Claude likes it or not, and can block the action outright.
The rule: "never touch .env" in CLAUDE.md is a preference. A PreToolUse hook that exits with code 2 is enforcement. If it must hold every time, it is a hook.
{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "npx prettier --write $CLAUDE_TOOL_INPUT_FILE_PATH" } ] } ] } }
- The
matchermatches the tool name, not your words. It is a regex and it is case-sensitive:Bashworks,bashdoes not. No spaces around the|. - Your script receives JSON on standard input — session id, tool name, and the tool's arguments — so it can decide based on the actual file path or command.
- Exit code 2 is the power move. From
PreToolUseit blocks the action and feeds your message back to Claude. FromStopit forces Claude to keep working — which is also how you build an infinite loop, so be careful. - A hook can be a shell command, an HTTP request, a prompt, or a whole subagent.
- Hooks cost zero context unless they return output. Output from a
PostToolUsehook lands in the conversation for Claude to read — which is how "run the linter, then fix what it found" works with no prompting.
The events you will actually use: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop, SubagentStop, PreCompact. There are around thirty in total and the list keeps growing — run /hooks to configure them interactively and to see the current set rather than trusting any article, including this one.
MCP — give it hands outside your folder
Claude Code can read your files and run your commands. It cannot see your database, your ticket tracker, or your browser. MCP is the standard plug that connects those, along with their authentication.
$ claude mcp add github -- npx -y @modelcontextprotocol/server-github $ claude mcp list > /mcp
/mcpinside a session shows connection status and what each server is costing you in context.- Servers can be scoped to just you, just this project, or this machine. When names collide: local beats project beats user.
- Their tools show up named
mcp__server__tool, which is also how you target them in hook matchers and permission rules. - Tool search is on by default, so idle servers cost very little context. Connecting fifteen servers still slows you down — disconnect what you are not using.
- Servers can expose ready-made commands as
/mcp__server__name.
MCP gives Claude the tools. A skill gives Claude the knowledge to use them well — your schema, your query patterns, your team's formatting rules. They are strongest together.
Background tasks — let the slow thing run while you keep talking
A build, a test suite, a dev server — anything slow does not have to freeze the conversation. Send it to the background and keep working; Claude tells you when it finishes.
> run the test suite in the background > /bashes
Ctrl+B does the same to a command that is already running. /bashes lists everything currently running in the background so you can check on it or kill it.
Worktrees — parallel work without stepping on your own feet
Normally Claude works in one folder on one branch. If you want it to try something risky, or work on a second thing while your main session keeps going, ask it to use a worktree: a second, isolated checkout of the same repo on its own branch. Nothing it does there touches your working copy until you decide to merge it back.
> start a worktree and try switching this to the new auth library
Good for an experiment you might throw away, or for running two unrelated tasks on the same repo at once without one's half-finished edits confusing the other.
Scheduling — work that happens without you present
Two different needs, two different tools. A loop repeats a prompt on an interval for as long as you leave it running — checking a deploy every few minutes, say. A scheduled agent runs later or on a recurring cron schedule, in the cloud, whether your laptop is open or not.
> /loop 5m check whether the deploy finished > schedule a routine that reviews open PRs every morning at 9am
Whether scheduled cloud agents are available depends on your plan. /help shows what your version has.
Plugins — the packaging layer
A plugin is a versioned bundle of skills, subagents, hooks, and MCP server definitions, installable in one command. This is how a setup stops living on your laptop and starts being something a team shares.
> /plugin > /my-plugin:review
Plugin skills are namespaced (/my-plugin:review) so two plugins can both ship a "review" without fighting. Marketplaces are how plugins get distributed. Vet anything from a marketplace the way you would vet a dependency — it is code and configuration that runs in your environment.
How everything layers when it overlaps
| Kind | What happens with duplicates |
|---|---|
| CLAUDE.md files | Additive — every level contributes at once. More specific instructions generally win |
| Skills and subagents | One definition wins by name. Roughly: managed > user > project > plugin |
| MCP servers | Win by name: local > project > user |
| Hooks | Merge — every registered hook fires, wherever it came from |
Context economics — why your setup can make things worse
Every feature costs some of Claude's attention. Too much and you do not just run out of room — you add noise, skills stop triggering correctly, and your conventions get lost in the crowd.
| Feature | Loads | Cost |
|---|---|---|
| CLAUDE.md | Session start, in full | Paid on every single request |
| Skills | Descriptions at start, full text when used | Low. Zero for user-only skills |
| MCP servers | Tool names at start, schemas on demand | Low until a tool is used |
| Subagents | Fresh context when spawned | Isolated from your session entirely |
| Hooks | Nothing — runs outside the conversation | Zero, unless it returns output |
This is why "move it to a skill" is usually the right answer to a bloated CLAUDE.md, and why a subagent is the right answer to a task that reads a hundred files.
The safety layer
Permission rules
Allow and deny lists in settings.json decide what never needs asking and what is never allowed. Deny rules beat everything.
Managed settings
An organisation can push settings that a project cannot override. This is how "our agents may not touch production" is actually made true.
Checkpoints
Esc Esc on an empty line opens the rewind menu: restore code, conversation, or both to an earlier point.
Sandboxing
For anything you would not run on your own machine, run it in a container. Bypass mode plus your home directory is how people get hurt.
Running it without a human
Everything above assumes you are sitting there. You do not have to be.
$ claude -p "summarise what changed in the last 10 commits"
- That is the doorway to scripting: pipe things in, pipe results out, run it from cron or CI.
- The Agent SDK exposes the same loop programmatically, including the hook lifecycle as in-process callbacks, if you want to build your own tool on top.
- There are official integrations for GitHub Actions and GitLab CI/CD, so Claude can respond on pull requests.
- Same tool, other surfaces: the web app, a desktop app, VS Code, JetBrains IDEs, and Slack. Your CLAUDE.md and skills come with you.
The order to actually add these
| When this happens | Add this |
|---|---|
| Claude gets a convention or command wrong twice | A line in CLAUDE.md |
| You type the same opening request again and again | A skill you invoke with /name |
| You paste the same multi-step playbook a third time | A skill containing the whole procedure |
| You keep copying data from a tab Claude cannot see | An MCP server |
| A side task floods your session with output you will never re-read | A subagent |
| You want something to happen every time, without asking | A hook |
| CLAUDE.md has grown past ~200 lines | Split it into .claude/rules/ and skills |
| A second repository needs the same setup | A plugin |
| Parallel workers need to talk to each other, not just report | An agent team |
| You want to try something without risking your working copy | A worktree |
| A slow command is blocking you from doing anything else | Ctrl+B to background it |
| Something needs to run on a timer, present or not | A loop, or a scheduled agent |
Versions move fast. This section was written against the docs in August 2026 and the feature set changes most weeks. /help, /hooks, and typing / on its own always describe the version you are actually running.
11Settings — make it look and feel right
Everything below is a real key from a working settings.json on an actual machine, not a guess from documentation. It lives at ~/.claude/settings.json for you personally, or .claude/settings.json to ship with a project. Edit the file directly, or run /config for the interactive version of the common ones.
Four settings that change how it feels
{ "showThinkingSummaries": true, "tui": "fullscreen", "fastMode": true, "statusLine": { "type": "command", "command": "$HOME/.claude/statusline.sh", "padding": 0 } }
showThinkingSummaries
Always shows a running summary of what Claude is thinking, not just the final answer. true is on.
tui: "fullscreen"
Switches to the alternate-screen full-window UI. In terminals that report mouse events — iTerm2, Kitty, WezTerm, Ghostty, Windows Terminal — this is also what lets you click to place the cursor and scroll with the wheel. Support depends on the terminal, not Claude Code; if clicking does nothing, yours may not report mouse events to apps.
statusLine
Runs your own script and prints its output as a status bar. command is any executable — shell, Python, whatever — that prints one line. Use it for the model name, git branch, cost, or all three.
fastMode
Faster output on plans that support it (Opus). It changes response speed, not the model tier.
Colors: Claude Code follows your terminal's own theme and color scheme — there is no separate color palette to configure in settings.json. If the colors look wrong, it is almost always the terminal profile, not Claude Code: check /config for light/dark mode, and check your terminal app's own theme/profile settings for the actual palette.
A starter settings.json, line by line
A reasonable personal default. Copy it, then delete anything you do not understand — do not run a block you cannot explain.
{ "model": "sonnet", "effortLevel": "high", "fastMode": true, "tui": "fullscreen", "showThinkingSummaries": true, "autoMemoryEnabled": true, "statusLine": { "type": "command", "command": "$HOME/.claude/statusline.sh", "padding": 0 }, "permissions": { "allow": [ "Read", "Write", "Edit", "Glob", "Grep", "Bash(git:*)", "Bash(npm:*)", "Bash(ls:*)", "Bash(cat:*)" ], "deny": [ "Read(**/.env)", "Read(**/*secret*)", "Read(**/credentials.json)", "Bash(rm -rf /*)", "Bash(curl * | sh)" ], "ask": [ "Bash(rm -rf:*)", "Bash(git push:*)", "Bash(git push --force:*)" ] } }
| Key | What it does |
|---|---|
model | Default model for new sessions. Overridden any time with /model. |
effortLevel | How hard it thinks before answering: low, medium, high, or max. Same as /effort, but persistent. |
fastMode | Faster output where the plan supports it. |
tui | UI mode. "fullscreen" is the full-window view with mouse support in terminals that offer it. |
showThinkingSummaries | Keeps the running thinking summary visible instead of just the final answer. |
autoMemoryEnabled | Lets Claude save its own notes across sessions — build commands, your preferences, project facts. See section 7. |
statusLine | Runs a script and shows its output as a status bar. |
permissions.allow | Tool and command patterns that never ask for confirmation. |
permissions.deny | Patterns that are never allowed, no matter what else is set. Deny always wins. |
permissions.ask | Patterns that always stop and ask, even in a mode that would otherwise skip confirmation. |
Permissions and hooks — the enforcement layer
The four modes in section 4 are a stance you take for a session. permissions.allow / deny / ask and hooks are rules that hold regardless of mode. Deny beats allow, and ask beats a mode that would otherwise skip confirmation.
{ "permissions": { "allow": [ "Bash(npm run lint)", "Bash(npm test:*)", "Read(~/.zshrc)" ], "deny": [ "Bash(sudo rm:*)", "Bash(git push --force *main*)", "Read(./.env)", "Read(./.env.*)" ], "ask": [ "Bash(rm -rf:*)", "Bash(git push:*)", "Bash(git reset --hard:*)" ], "defaultMode": "acceptEdits" } }
{ "hooks": { "Stop": [ { "hooks": [ { "type": "command", "command": "npm test --silent || echo 'Tests are failing — fix them before stopping.'" } ] } ] } }
permissions.defaultModesets which of the section-4 modes a session starts in —"acceptEdits","plan", or"bypassPermissions".bypassPermissionsskips confirmation for everything not explicitly denied — only use it in a throwaway folder or a container, never on your main machine with your real files.- Run
/permissionsinside a session to edit these lists without opening the file by hand. - Rules are patterns, not exact strings:
Bash(git:*)allows anygitsubcommand,Read(**/*secret*)denies any file with "secret" anywhere in its name. - An organisation can push settings a project cannot override — see section 10's safety layer for how that fits together.
If you only take one thing from this section: set showThinkingSummaries: true and tui: "fullscreen" today — zero risk, immediate difference. Touch permissions and hooks only once you have read what each rule actually does; a wrong deny rule silently blocks something you needed, and a wrong allow rule silently skips a confirmation you wanted.
12Tips it shows you
These are real tips from Claude Code's own rotating tip pool — the lines that flash under the input while it's thinking, or at the start of a session. Pulled directly from an installed copy (version 2.1.233, August 2026), not guessed. The pool changes with every release, so treat this as a snapshot, not a permanent list — new ones ship all the time.
Sessions & organization
- Running multiple Claude sessions? Use
/colorand/renameto tell them apart at a glance. - Name your conversations with
/renameto find them easily in/resumelater. - Run
claude --continueorclaude --resumeto resume a conversation. - Use
/clearto start fresh when switching topics and free up context. - Use
/btwto ask a quick side question without interrupting Claude's current work.
Terminal & display
- Run
/terminal-setupto enable convenient terminal integration, like Option+Enter or Shift+Enter for a new line. - Corrupted terminal glyphs? Disable terminal GPU acceleration in your terminal's own settings, or run
/terminal-setup. - Try setting the environment variable
COLORTERM=truecolorfor richer colors. - Use
/themeto change the color theme. - Did you know you can drag and drop image files into your terminal?
- Paste images into Claude Code with Ctrl+V — not Cmd+V, even on a Mac.
Working with Claude
- Hit Enter to queue up additional messages while Claude is working.
- Send messages to Claude while it works, to steer it in real time.
- Ask Claude to create a todo list for complex tasks, to track progress and stay on track.
- Double-tap Esc to rewind the code and/or the conversation to a previous point in time.
- Shift+Tab cycles between manual mode, auto-accept edit mode, and plan mode.
- Use
/permissionsto pre-approve or pre-deny specific bash, edit, and MCP tool calls.
Memory, skills & setup
- Use
/memoryto view and manage what Claude remembers. - Create skills by adding
.mdfiles to.claude/skills/in a project, or~/.claude/skills/for skills that work everywhere. - Use
/statuslineto set up a custom status line that displays beneath the input box.
Agents, subagents & workflows
- Use
--agent <agent_name>to start a conversation directly with a subagent. - Say "fan out subagents" and Claude sends a team — each one digs deep so nothing gets missed.
- Dynamic workflows let Claude write a script that orchestrates many agents for you. Mention the keyword "ultracode," or ask Claude to use a workflow directly.
- Control how big a workflow is just by prompting — try "use a small workflow, 5 agents max," or set a default under Dynamic workflow size in
/config. - Scheduling lets you run any prompt on a recurring schedule — good for monitoring deploys, babysitting PRs, or polling status.
Reviews & feedback
- For a fast, cheap code review, try
/code-review low— it runs the built-in skill at its lightest effort level. - Run
/ultrareviewfor a cloud-based, multi-agent review that finds and verifies bugs in your branch. - Use
/feedbackto help Anthropic improve Claude Code.
IDE & integrations
- Connect Claude to your IDE from its Command Palette — install the shell command once, and Claude Code can see what you see.
- Run
/install-github-appto tag@clauderight from your GitHub issues and PRs. - Run
/install-slack-appto use Claude in Slack. - Working with HTML/CSS? Install the frontend-design plugin with
/plugin install.
Claude beyond the terminal
- Run Claude Code locally or remotely using the Claude desktop app.
- Working on UI? Claude Code Desktop has a live preview and inline images.
- Use Claude Design to mock up screens before you build.
- Run tasks in the cloud while you keep coding locally.
- Control this session from the Claude mobile app, or drive it from
claude.ai/codein any browser. - Get pinged on your phone when a long task finishes — enable push notifications.
- Use
/voiceto enable push-to-talk dictation. - Build your own AI product on the Claude API — run
/claude-apito get started.
If your default model is Opus: one startup tip is worth calling out on its own — press Shift+Tab twice to activate Plan Mode and plan with Opus before executing.
Turning it off: the whole feature is one setting — "spinnerTipsEnabled": false in settings.json. See section 11 for where that file lives and what else is in it.
13File prompts — things to paste when you're staring at your own files
Claude Code can read, search, rename, convert, and reorganize the files already on your computer — not just code. Open a terminal, run claude in whatever folder you care about (or just your home folder), and paste any of these. Each one is a full, ready-to-use prompt — swap the specifics for your own folder names, then go from there.
Find things
Find every file on my computer over 1GB and list them by size, biggest first
Find every duplicate file in my Downloads folder
Find every file I've touched in the last 24 hours anywhere in my home folder
Search my whole Documents folder for any file that mentions the word "invoice"
Find every screenshot on my Desktop
Organize & clean up
Look at everything in my Downloads folder and suggest a clean folder structure for it
Move every screenshot on my Desktop into a new "Screenshots" folder, renamed by the date it was taken
Go through my Desktop and tell me what looks safe to delete versus what I should keep
Rename every file in this folder to lowercase kebab-case with no spaces
Find every empty folder on my computer and list them
Rename & batch-edit
Add today's date as a prefix to every file in this folder
Renumber all the files in this folder so they sort in the right order
Strip the "(1)", "(2)", etc. off every duplicate-named file in this folder
Convert & transform
Convert every .jpeg in this folder to .png
Convert this CSV into a clean, readable Markdown table
Combine these Markdown notes into one clean PDF
Resize every image in this folder to under 2MB without visibly hurting quality
Search & extract
Search every PDF in this folder for the word "contract" and tell me which ones mention it
Read every text file in this folder and pull out every email address mentioned
Read this spreadsheet and tell me the three biggest outliers in the [column name] column
Summarize every PDF in this folder in one sentence each
Compare & verify
Compare these two folders and tell me exactly what's different between them
Compare this file against yesterday's backup and summarize what changed
Check if this folder is already backed up anywhere else on this computer
Back up safely
Before I delete anything in this folder, make a zipped backup of it in my Documents folder first
Make a dated backup of this whole project folder
Understand what you're looking at
Look at everything in this folder and explain, like I've never seen it before, what this project is
Read through my notes folder and tell me the recurring themes across everything in there
Find every file in this folder I haven't touched in over a year
Go through my whole computer and tell me what's taking up the most disk space
These run locally: Claude Code only ever touches files inside (or explicitly pointed at) the folder you launched it from — nothing is uploaded anywhere just to look at it. For anything destructive (deleting, overwriting), it will ask first unless you've set permissions to skip that.
14The master prompt — get a real plan for a struggling website
This one is different from the rest: it's a single template, not a list. Fill in the brackets with your real situation, paste the whole thing into Claude Code, and it will actually go look at your live site, research your situation, and hand back a concrete, ranked plan — not generic advice copied from a blog post.
I run [type of business]. Here's my situation: - What we do: [one or two sentences] - The problem: [e.g. "we have open positions/openings/inventory but almost nobody is applying/booking/buying through our website"] - Where it seems to break down: [e.g. "barely any visitors at all" / "visitors land on the site but don't take action" / "not sure — that's what I need you to find out"] - Tools we already use: our CRM/ATS/booking system is [name], our website is hosted on [host], our domain is [domain] - Who has access to make changes: [you / you and a developer / just you] - What success looks like: [e.g. "5 more qualified applicants a week"] Here's what I want you to do: 1. Pull up my website ([URL]) and actually look at it — load speed, mobile experience, how it reads to a total stranger, whether the call-to-action is obvious. 2. Research how people who need a business like mine normally search, and figure out where my site is realistically losing them. 3. Check whether the site is even indexed and showing up for the terms someone would actually type in. 4. Give me a specific, ranked list of what's actually wrong with THIS site — not generic SEO advice. 5. Then build me something I can act on immediately: either an Artifact that walks me through exactly what to fix and in what order, or a small local page I can open in my browser that tracks the fixes as I make them. Don't soften it — if the real problem is something other than the website itself, tell me that too.
Why it's written this general: this prompt is deliberately built for any small business, not one specific industry — it was inspired by a family recruiting firm with open jobs and no applicants, but the same shape works for a bakery with no walk-ins, a repair shop with no bookings, or a shop with no online sales. Fill in your own details and it adapts.