Claude Code is powerful out of the box, but the settings that actually save you time and money are switched off by default. Here are the 6 I turn on first, with a ready-to-paste settings.json at the end.
Most people install Claude Code, start typing, and never open a single setting. It works, so why touch it? Because the defaults are built to be safe for everyone, not fast for you. The minute you change a few things, it stops feeling like a clever chatbot in your terminal and starts feeling like a teammate who knows your project.
These are the 6 I change on day one, every single time. None of them are hard. Most are one file or one command. At the bottom I give you my whole settings.json to copy and paste.
One Thing To Know First
Claude Code reads its settings from a hidden folder called .claude that lives inside your project. Files in there (like settings.json, or a commands and agents folder) only apply to that project, so you can give every project its own setup. New to this? Everything below tells you the exact file and where it goes.
Your Panic Button
Press Esc Twice Or Type /rewind
Claude went rogue and rewrote half your files? Do not panic and do not start manually fixing things. Press Esc twice (or type /rewind) and Claude opens a list of checkpoints from this session. Pick a point and it rolls back both your code AND the conversation to exactly how they were then. It is a time machine for the whole session, not just an undo for the last edit.
This is the single setting that makes people brave enough to actually let Claude work. You stop hovering, because you know any mess is one keystroke away from being erased.
The Honest Limit
Rewind controls your files and the chat. It will not reverse things that already left your machine, like a git push, a deploy, or a database change. Treat those as permanent. For everything local, rewind has your back.
Write It Once, Run It Forever
Turn Your Repeat Prompt Into /yourcommand
That prompt you paste five times a day? Stop pasting it. Make a folder called .claude/commands in your project, drop in a plain text file like review.md, and put your prompt inside. Now typing /review runs it instantly. The file name becomes the command name.
Here is a real one I would actually use. Save this as .claude/commands/review.md and you get a /review command forever.
Save as .claude/commands/review.md
--- description: Review my staged changes for real bugs and confusing names --- Look at the changes I have staged in git (run `git diff --staged`). Review them like a sharp senior engineer who is short on time. For each issue you find, 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 genuinely matter. Skip style nitpicks and personal preference. - If something could silently break in production, say so loudly and put it at the top. - If the changes look clean, just say "Looks good" and stop. Do not invent problems to seem useful.
What To Do With It
Make the folder, save that file inside it, then type /review in Claude Code. That is it. Build one of these for every prompt you reuse: /standup to summarize what you did, /test to write tests for the file you just changed, /explain to break down code you inherited. Each is just a text file you write once.
It Checks Its Own Work
Drop In A Subagent
A subagent is a second Claude that your main Claude can hand work to. The magic is that it runs in its own clean context, a fresh mind that has not been staring at the same code for an hour. So when it reviews, the review stays honest and your main chat stays focused on building.
Make a folder called .claude/agents and drop in this file. Now your main Claude can send its work to a dedicated reviewer whenever you (or it) wants a second pair of eyes.
Save as .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. model: haiku --- You are a focused senior code reviewer. You were handed a set of recent changes to review with completely fresh eyes. 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, user data, or 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 Be direct and specific. Do not pad. If the change is genuinely clean, say so in one line and stop. Never invent issues to look thorough.
What To Do With It
After you save it, just ask your main Claude: "Use the code-reviewer subagent to check what you just built." It spins up the reviewer in its own context, gets the honest report back, and keeps going. Notice the model: haiku line, that runs the reviewer on the cheap fast model so a thorough review barely costs you anything. More on that next.
Stop Overpaying On Easy Work
Match The Model To The Job
Running your most expensive model on everything? You are burning through your usage way faster than you need to. A project that is mostly scraping, renaming, and editing docs does not need a genius on every keystroke. A project full of hard architecture decisions does.
Set a default model per project by adding one line to that project's .claude/settings.json. The light, repetitive projects get Haiku (fast and cheap). The hard, high-stakes builds get Opus or Fable. You can always switch on the fly with the /model command, but setting a smart default per project means you stop paying premium prices for grunt work without thinking about it.
Quick Rule Of Thumb
Haiku for scraping, formatting, simple edits, bulk tasks. Opus for real building and most serious work. Fable 5 for the hardest, longest, most complex jobs (it is the premium model, so save it for when you truly need maximum brainpower). New Fable 5? Here is my full Fable guide.
Guardrails It Can Never Cross
Block The Commands That Wreck Your Machine
Before you let Claude move fast, give it a hard line it can never step over. In your .claude/settings.json, a permissions.deny list names the things Claude is flat-out not allowed to do, no matter what. Deny rules beat everything, even the "just do it" mode from setting 6. A deny rule is a guardrail, not a suggestion.
The essentials to block: the command that can wipe folders, anything run as the all-powerful admin user, and reading your secret files.
· Bash(rm -rf:*) blocks the wipe-a-folder command
· Bash(sudo:*) blocks running anything as admin
· Read(.env) blocks reading your secret keys
· Read(./secrets/**) blocks your whole secrets folder
Then add one lock the operating system itself enforces, so even a rogue process cannot read your keys: chmod 600 .env (run that once in your terminal, it makes the file readable only by you).
Go Deeper
This pairs with an allow list (the safe commands Claude can run without asking). The full system, allow plus deny and why deny always wins, is in my Claude Code safety guide. The ready-to-paste file below already has both lists in it.
Let It Actually Work
Turn On Accept Edits Mode
If you sit there approving every single edit, you lose the whole point of having a teammate. You are not building, you are babysitting. Set Claude's default mode so it applies its own edits to files without stopping to ask each time:
"permissions": { "defaultMode": "acceptEdits" }
This is safe precisely because you did setting 5 first. Claude can now edit freely, but it still asks before running commands, and your deny list means the dangerous ones are blocked no matter what. You get the speed of letting it run, with the guardrails holding underneath.
The Order Matters
Build the deny list before you flip on accept-edits, never after. The guardrail has to exist before you take your hands off the wheel. Do them together, in the one file below, and you are covered.
Here is the whole thing in one file. It sets your model, turns on accept-edits, allows the safe everyday commands, and blocks the dangerous ones. Settings 4, 5, and 6 are all in here. Paste it, tweak it, and your project is set up like a power user's.
Save as .claude/settings.json in your project
{
"model": "opus",
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Bash(npm run test:*)",
"Bash(npm run lint:*)",
"Bash(npm run build:*)",
"Bash(git status)",
"Bash(git diff:*)",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(ls:*)",
"Bash(cat:*)",
"Bash(grep:*)",
"Read(./**)"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(sudo:*)",
"Bash(git push:*)",
"Bash(git reset --hard:*)",
"Bash(curl:* | sh)",
"Read(.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./**/*.pem)",
"Read(./**/id_rsa)"
]
}
}
What To Do With This
In your project, open the .claude folder (or make one), create a file called settings.json inside it, and paste this in. Change "opus" to "haiku" for light projects or "claude-fable-5" for your hardest ones. Add your own safe commands to the allow list as you notice yourself approving the same thing over and over. The deny list is your floor, keep it strict. Then run chmod 600 .env once in your terminal for the OS-level lock.
The Real Win
Twenty minutes of setup and Claude Code stops being a careful assistant you have to supervise and becomes a fast teammate you can trust. It can undo anything, runs your favorite prompts as commands, reviews its own work, uses the right model for the job, and moves at full speed inside guardrails it can never cross. That is the difference between people who play with Claude Code and people who build with it.
The Only AI Masterclass You Need
If this guide helped, but you’re looking to go deeper, I got you!! My 30-Day Challenge takes you from saving AI tips you never use to actually building with AI, step-by-step.
I show you exactly how I automated two e-commerce brands, my social media, and most of my personal life, then hand you the agents, workflows & systems to do the same. I’m teaching you every single thing I know with one lesson and one build a day.
Join the AI Masterclass →© 2026 Mariah Brunner. All rights reserved.