The settings that change everything

Permissions: stop approving endlessly

By default, Claude asks permission before every shell command and every file modification. That's the right starting point: as long as you don't know what the tool is doing, every action deserves a look. But after an hour, you'll have approved ls, cat, and git status thirty times — read-only commands that can't break anything. That friction has a real cost: it interrupts your focus and, worse, it trains you to click "yes" mechanically, which defeats the very purpose of the control.

The solution: authorize non-destructive commands once and for all, and keep manual approval for the ones that change your system's state or touch the network in sensitive ways. Claude Code's permission system relies on allowlists per tool and per command pattern, stored in configuration files. You can view and edit them at any time with the /permissions command.

The easiest way to start: paste this prompt into Claude Code — it will update your .claude/settings.local.json file, where your local permissions live:

add permissions to this claude code project to allow non-destructive bash commands: WebSearch, WebFetch, source, export, curl, jq, cat, ls, grep, echo, which, wc, file, pwd, mkdir, touch, head, tail, find, sort, tree, diff, node, npm, npx, git status, git diff, git log

Anatomy of the configuration files

Claude Code reads its settings at three levels, from most general to most specific: ~/.claude/settings.json (your personal settings, valid everywhere), .claude/settings.json (the project's settings, versioned in Git to share with a team), and .claude/settings.local.json (your local settings for this project, ignored by Git). Permissions granted "for this project" land in the latter.

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "WebSearch",
      "WebFetch(domain:docs.anthropic.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)"
    ]
  }
}

Read this file once to understand the logic: each entry combines a tool (Bash, WebFetch…) and a pattern. Bash(git diff:*) allows git diff with any arguments, but not git push. The deny list always wins over allow: it's your safety belt, even if an allow rule is too broad.

Modes: Plan vs Auto-Edit

Beyond per-command permissions, Claude Code has permission modes that control its overall level of autonomy. In the terminal, you switch between them with Shift+Tab; in the extension, a selector does the same. The habit of experienced users: spend most of the thinking phase in Plan Mode or Ask Before Edits.

In Plan Mode, Claude touches nothing: it reads, analyzes, and presents you with a detailed action plan. That's where everything is decided. You read what it proposes, you debate, you request revisions: "why this approach rather than that one?", "add a verification step here." As long as the plan isn't approved, you stay in restrictive mode. Once the plan is locked, you switch to Auto-Edit (automatic acceptance of changes) and let it execute fast, without interrupting you at every file.

• Plan Mode → design phase: Claude reads and plans, modifies nothing. Ideal for complex or unfamiliar tasks.
• Ask Before Edits (default) → Claude proposes each change and waits for your approval. A good everyday compromise.
• Auto-Edit → execution phase: the plan is approved, Claude moves forward without interrupting you on file edits.

flowchart LR
  A["Plan Mode: Claude proposes"] --> B{"Plan approved?"}
  B -->|"No: debate, revise"| A
  B -->|"Yes"| C["Auto-Edit: fast execution"]
  C --> D["Review the result"]
  D --> E["/clear then next task"]

YOLO mode: handle with care

There's one level above: launching Claude Code with claude --dangerously-skip-permissions, which disables all permission prompts. The name is explicit — it's intentionally intimidating. This mode has legitimate uses: long, well-scoped tasks (fixing lint errors across 50 files, generating boilerplate) where every interruption defeats the point of automating.

But understand what you're signing up for: Claude can then run any command without consulting you. Anthropic's recommendation is to reserve this mode for isolated environments — a Docker container, a virtual machine, a folder with no sensitive data. On your main workstation, with your real client files, stick to allowlists: you get 95% of the fluidity with 5% of the risk.

Context: starting fresh with /clear and /compact

Every conversation with Claude lives inside a context window: the model's working memory. Everything goes in — your messages, its replies, the contents of files it reads, command outputs. That window is large but finite, and above all: the more it fills with things unrelated to your current task, the worse the answers get. The model starts mixing topics, dragging up decisions from a previous task, losing the thread.

When you start a new task (new feature, fix, different topic), clean the conversation to start from a fresh context. Two commands exist, and they don't do the same thing:

The right reflex: /clear by default between tasks, /compact only when you're in the middle of something long and Claude warns you the context is filling up. Note that Claude Code also triggers automatic compaction when the window approaches saturation — but a compaction you choose at the right moment (after a completed step, not mid-reasoning) preserves quality better.

The shortcut that reloads your context

"But if I /clear, Claude forgets my whole project!" Exactly — and that's why chapter 8 exists. The CLAUDE.md file, read automatically at the start of every session, holds your project's permanent context. /clear wipes the conversational noise; CLAUDE.md guarantees the essentials always come back.

An expert tip in the meantime: create a shortcut (for instance a small qnew command) that asks Claude to reread your CLAUDE.md and summarize where the project stands. That way every session restarts with the full project context, minus the noise of past conversations. You'll see in chapter 8 how to build that file properly.