← Back to all free guides
A free guide by Mariah Brunner ↗ INSTAGRAM ↗ TIKTOK

6 Claude Code
Power User Settings

Claude Code works out of the box, but the setup that saves you time and money takes a few minutes. Here are the 6 I do first, with a ready-to-paste settings.json at the end.

Most people install Claude Code, start typing and never open a setting. The defaults are built to be safe for everyone, not fast for you. Change a few things and it starts feeling like a teammate who knows your project.

One Thing To Know First

Claude Code reads project settings from a hidden folder called .claude inside your project. Files in there, like settings.json or the skills and agents folders, only apply to that project. Every step below tells you the exact file and where it goes.

The 6 Settings

01

Undo anything with /rewind

Claude rewrote half your files? Don’t start fixing by hand. Type /rewind, or press Esc twice with an empty prompt box. Pick an earlier prompt and choose Restore code and conversation, or just the code, or just the chat. Checkpoints even survive when you resume a session. (Checkpointing docs)

This is what makes people brave enough to let Claude work. Any mess is a keystroke away from gone.

The Honest Limit

Rewind tracks edits made with Claude’s file tools. A file that only a terminal command changed isn’t tracked, and edits a subagent makes may not come back. It also can’t undo anything that left your machine, like a git push, a deploy or a database change. Keep using Git for anything that matters.

02

Build your own slash command

That prompt you paste five times a day? Turn it into a command. Make a folder at .claude/skills/quick-review/ and save the file below inside it as SKILL.md. Now typing /quick-review runs it. The folder name becomes the command name. (Skills docs)

.claude/skills/quick-review/SKILL.md
--- description: Review my staged git changes for real bugs, security holes and confusing names. Run only when I type /quick-review. disable-model-invocation: true --- Look at the changes I have staged in git (run `git diff --staged`). If nothing is staged, review `git diff` instead and tell me you did. Review them like a sharp senior engineer who is short on time. For each issue, give me exactly three lines: - The file and line number - What is actually wrong (a real bug, a security hole, or a confusing name) - The smallest possible fix Rules: - Only flag things that matter. Skip style nitpicks and personal preference. - If something could silently break in production or leak data, say so loudly and put it at the top. - Don't edit any files. This is a review, not a fix. - If the changes look clean, say "Looks good" and stop. Don't invent problems to seem useful.

The disable-model-invocation line means it only runs when you type it. Older .claude/commands/ files still work too, but Anthropic now recommends the skills folder. Build one for every prompt you reuse, like a standup summary or a test writer.

03

Give Claude a code reviewer

A subagent is a second Claude your main one hands work to. It runs in its own context window, a fresh mind that hasn’t been staring at the same code for an hour, and only its summary comes back to your chat. Save this file as .claude/agents/code-reviewer.md. (Subagent docs)

.claude/agents/code-reviewer.md
--- name: code-reviewer description: Reviews recent code changes for bugs, security and clarity in a clean, separate context. Use after writing or editing code. tools: Read, Grep, Glob, Bash model: haiku --- You are a focused senior code reviewer. You were handed a set of recent changes to review with completely fresh eyes. Start by running `git diff` to see what changed. Review only what changed. For each problem, report: - The file and the line - The category: BUG, SECURITY, or CLARITY - One sentence on what is wrong - The smallest concrete fix Priorities, in order: 1. Anything that could break in production or lose data 2. Anything that exposes secrets or user data, or opens an injection risk 3. Logic that is subtly wrong (off-by-one, wrong condition, bad default) 4. Names and structure that will confuse the next person Don't edit files. Report back only. Be direct and specific, and don't pad. If the change is clean, say so in one line and stop. Never invent issues to look thorough.

Then ask: "Use the code-reviewer subagent to check what you just built." To guarantee it runs, type @ and pick it from the list. The model: haiku line runs it on the cheap, fast model. Swap in sonnet for a tougher review.

04

One model per project

Running your priciest model on everything burns usage fast. Add a "model" line to a project’s .claude/settings.json and that project starts on it. Use haiku for bulk edits and formatting, opus (Opus 5.5) for real building, and fable (Fable 5.1) only for the hardest, longest jobs. (Model docs)

You can still switch anytime with /model. Heads up: that also saves your pick as your default. Fable on Pro bills to usage credits. Here’s my full Fable guide.

05

Build a deny list

Give Claude a hard line it can never cross. A permissions.deny list in .claude/settings.json names what Claude is never allowed to do. Claude Code checks deny rules first, then ask, then allow, so a deny rule wins in every mode. (Permission docs)

  1. Bash(rm -rf *) blocks the wipe-a-folder command.
  2. Bash(sudo *) blocks running anything as admin.
  3. Read(.env) blocks Claude from reading your secret keys file.
  4. Read(./secrets/**) blocks your whole secrets folder.

Deny rules cover Claude’s file tools and common commands like cat, but a script Claude writes could still open a file on its own. For a lock the operating system enforces, turn on the sandbox with /sandbox (macOS, Linux and WSL2). (Sandbox docs)

The full allow plus deny system is in my Claude Code safety guide.

06

Pick your permission mode

Press Shift+Tab to cycle modes. On current versions, new terminal sessions start in auto mode, where a background check reviews each command against your request so you aren’t clicking approve all day. (Permission modes)

Rather approve commands yourself? Use accept edits mode ("defaultMode": "acceptEdits"). Claude edits files and runs basic file commands like mkdir and mv on its own, but asks before anything else. Either way, build your deny list first, because it holds in every mode.

My Ready-To-Paste settings.json

Here’s settings 4, 5 and 6 in one file. It sets your model and mode, allows the safe everyday commands and blocks the dangerous ones. Save it as .claude/settings.json in your project.

.claude/settings.json
{ "model": "opus", "permissions": { "defaultMode": "auto", "allow": [ "Bash(npm run test *)", "Bash(npm run lint *)", "Bash(npm run build *)", "Bash(git add *)", "Bash(git commit *)" ], "deny": [ "Bash(rm -rf *)", "Bash(rm -fr *)", "Bash(sudo *)", "Bash(git push *)", "Bash(git reset --hard *)", "Read(.env)", "Read(.env.*)", "Read(./secrets/**)", "Read(**/*.pem)", "Read(**/id_rsa)" ] } }
  1. Change the model to "haiku" for light projects or "fable" for your hardest ones.
  2. Grow the allow list when you notice yourself approving the same command over and over. Read-only commands like ls, cat and git status already run without asking.
  3. Keep the deny list strict. It’s your floor. Swap "auto" for "acceptEdits" if you want to approve commands yourself.

The Real Win

Twenty minutes of setup and Claude Code can undo anything, run your favorite prompts as commands, review its own work, use the right model for the job and move fast inside guardrails it can’t cross.