How to Set Up Claude Code the Right Way
How to set up Claude Code: one folder per project, Git for undo, a permission mode you understand, and a rule that blocks secret files. Then stop.

To set up Claude Code the right way, give each project its own folder, keep that folder in Git, choose a permission mode you understand, and block Claude from reading your secret files. Then stop. Almost everything else can wait until a real problem asks for it.
That’s a short list. Most setup guides give you a long one. Here’s why the short one is right.
Doesn’t setup mean a lot of configuration?
No. That’s the first assumption to drop.
Anthropic’s own best-practices guide says your first plain prompt in a fresh session usually does the right thing, with no setup. Setup matters only where your project has rules Claude can’t see.
So don’t start by copying someone’s 300-line settings file. Start from what’s true about how Claude Code works, and add only what those facts demand.
There are five of them.
Fact 1: where does Claude Code work?
Inside the folder you start it in. It reads, writes and runs commands there.
So: one folder per project. Your website gets a folder. Your price calculator gets a different folder. Don’t start Claude Code in your whole Documents folder and hope it finds the right files.
Fact 2: what happens when it changes a file?
The file changes on your disk. Changes need a way back.
Claude Code has a built-in one. It saves a checkpoint every time you send a prompt. Press Esc twice on an empty prompt, or type /rewind, to restore an earlier point.
But checkpoints have limits. A file changed only by a shell command isn’t tracked. And the docs say plainly that checkpoints don’t replace version control.
So: put every project in Git. Ask Claude Code to “set up git in this folder” on day one. Then you can undo anything, not just the last few prompts.
Fact 3: how does it decide what it’s allowed to do?
Through permission modes. Each mode sets what Claude can do without asking you first.
| Mode | What it does without asking |
|---|---|
Manual (default) | Only reads. Asks before edits, commands and network access |
acceptEdits | Edits files and runs basic file commands in your folder |
plan | Reads and proposes a plan. Edits nothing until you approve |
auto | Runs actions, with a separate check reviewing risky ones first |
New terminal sessions start in auto mode where your account and model support it. Otherwise they start in Manual.
Press Shift+Tab to cycle modes during a session. From auto, the first press takes you to Manual.
There’s also bypassPermissions, which skips the checks entirely. It’s meant for isolated test machines. Don’t use it on the computer you work on.
So: learn the four modes above. If you’re new and want to approve every change, switch to Manual. Use plan before any big job.
Fact 4: where do settings live?
In plain JSON files, at three levels.
| File | Who it affects |
|---|---|
~/.claude/settings.json | You, in every project |
.claude/settings.json in the project | Everyone in the project, if you commit it |
.claude/settings.local.json in the project | Just you, in this project. Kept out of Git |
When two files set the same thing, the closer one wins. Project local beats shared project, which beats your user file. On Windows, ~ means C:\Users\YourName.
You don’t have to create any of them. When you answer “Yes, and don’t ask again” on a permission prompt, Claude Code writes that rule into .claude/settings.local.json for you.
So: leave these files alone until you need one rule. Then put it in the narrowest file that works.
Fact 5: what should Claude never see?
Your secrets. Passwords, API keys, the .env file most projects keep them in.
Claude Code reads files in your folder as it works. A deny rule stops that for the files you name. This goes in ~/.claude/settings.json:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}
The file must be strict JSON. No comments, no trailing commas, or Claude Code reports a settings error at the next start.
So: add this rule before your first project with a real password in it.
What does the right setup look like, rebuilt?
Put the five facts back together and the setup writes itself:
- One folder per project.
- Git in every project folder.
- A permission mode you chose on purpose.
- Settings files left alone until you need a rule.
- A deny rule for your secret files.
Run /init in a project and Claude Code writes a starting CLAUDE.md, a short file it reads at the start of every session.
Then check your work. Type /status inside Claude Code to see which settings files loaded. Run claude doctor in your terminal to see anything it rejected.
What can you skip for now?
Hooks, MCP servers, plugins and custom subagents. They’re all real features. None of them is setup.
Add each one when a specific job needs it. You’ll know, because you’ll be stuck without it.
I’m on the $100 Max plan and use Claude Code every day to build websites for local businesses. You don’t need that plan to start. Pro at $20 a month is enough to learn on; here’s what each plan includes.
Frequently asked questions
Where is the Claude Code settings file?
Your personal one is ~/.claude/settings.json. Project files live in a .claude folder inside the project: settings.json for the team and settings.local.json for you. None exist until you or Claude Code create them.
How do I stop Claude Code asking permission every time?
Choose “Yes, and don’t ask again” on a prompt, and Claude Code saves that as a rule. Or press Shift+Tab to switch to acceptEdits or auto mode.
Should I commit .claude/settings.json to Git?
Yes, if other people work on the project and should share its rules. Keep personal preferences in .claude/settings.local.json, which Claude Code keeps out of Git when it creates the file.
Do I have to set anything up before my first session? No. Install, log in and start. The 30-minute tutorial works with no setup at all.
Haven’t installed it yet? Start with How to Install Claude Code, or watch my free video, where I build a real site with Claude Code start to finish. Watch the free video.