CLAUDE.md plus safe permissions: the setup that prevents your first disaster

The first disaster in Claude Code almost never comes from too little studying. It comes from one permission left too open in week one. You request a plain tweak, the agent suggests deleting a folder, running a destructive command, or reading a file with a key, and hurry makes you confirm without reading. That scene repeats because plenty of people skip setup to reach the productive part sooner.

This guide locks the two pieces that prevent the scare: the permission mode and the CLAUDE.md file. You leave with plan permission mode on, a ready allow, ask, and deny list to copy, a short CLAUDE.md template with a test command, and a two-minute review routine. If you skipped the starter drill, begin with the overview map at Claude Code from zero. Plan mode plus the JSON permissions structure with .env and destructive-command blocks follows the walkthrough published Apr 8, 2026 in the getting-started guide.

Plan permission mode is the safe starting point because it flips the risk order. First the agent shows the plan, then it asks approval at sensitive points, and only then it runs. That sequence reads as the recommended beginner mode in the getting-started guide, Apr 8, 2026.

In practice, plan changes your day in three details. Reading and explanation requests arrive fast, with no lock. Edit requests arrive as proposals, with files cited and a predicted diff. Sensitive-command requests stop for confirmation, with the exact command on screen. You keep speed where nothing risks breaking and gain a pause where it does.

Enable the mode with the command below inside the session, then confirm in the permission list:

/permissions

Open /permissions, pick plan as the active mode, and read the current list before the next request. If any item looks too broad, move it to ask on the spot. The early-days rule runs plain: when in doubt, keep the stricter option.

Strict permissions look slow and run the opposite way. Every answered ask becomes knowledge of what is safe. Every premature allow becomes an incident that eats an afternoon. Here safety never delays the work, it buys speed without scares.

Leave plan only once two signals show up together. First, you already review short diffs calmly and understand each line. Second, the ask list repeats only commands you approved many times with no scare. Even then, promote one command at a time to allow, never free everything at once.

The three layers do distinct jobs worth memorizing. Allow frees without asking and serves only reading plus harmless daily commands. Ask confirms case by case and serves everything that alters files or ships code. Deny blocks for good and serves secrets plus destructive commands. That allow, ask, deny split with JSON permissions sits in the getting-started guide, Apr 8, 2026.

Copy the template below as a starting point, and adjust the test commands to your project:

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Bash(npm test:*)",
      "Bash(npm run build:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)"
    ],
    "ask": [
      "Edit",
      "Bash(git commit:*)",
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(.env)"
    ]
  }
}

Each group carries a clear reason. Allow holds reading with Read and Grep, checking with git status and git diff, and validation with npm test and npm run build. Ask holds writing with Edit and shipping with git commit and git push, because those points deserve your eyes first. Deny locks removal with rm -rf, forced shipping with force push, and secret reading with .env reads. The .env plus removal and force-push blocks are the safe default from the Apr 8, 2026 guide.

Use the table below for a two-minute list review:

When a new command lands in ask and you do not recognize the effect, request an explanation before approving. One sentence does it: explain what this command does in this project, without running it. If the explanation cites real files and folders from your context, approve. If the answer stays vague or cites strange paths, refuse and retune the request with the exact folder.

CLAUDE.md is an instruction file at the project root telling the agent how to work there. Short files work better because they review easy and invite fewer contradictory orders. The advice to hold that file small, 5 to 10 lines at the start, comes from the tutorial published Jan 28, 2026 in the beginner tutorial.

The file's first useful piece says how to validate the work. Without the test command there, every answer suggests a different way to check. With it, the agent already proposes your project's right command. That first-line-with-tests role sits in the guide from Apr 27, 2026 in the complete getting-started guide.

Copy the minimal template below, swapping the name and command for your project's real ones:

# project-name

Node project with Jest tests.

## How to validate
Run `npm test` before finishing any change.

## Style
Short answers, one small diff at a time.

## Limits
Never read `.env`. Never run `rm -rf` or `git push --force` without explicit permission.

Each block does one direct job. Context says what the project is in one sentence. Validation names the exact command proving a change works. Style asks for small diffs, which review line by line with ease. Limits list what never happens without explicit say-so, with .env and destructive commands on top.

Generate the base with the command below, then edit it down, never up:

/init

/init drafts from the project files. Open the result, cut generic sentences, leave the exact test command, and hold limits to a few lines. Past one short screen, cut again. A lean file guards better because you actually read it before each session.

That test-validation habit comes from the starter drill. If you never ran the read, change little, review-diff-with-tests cycle, follow the first-30-minutes walkthrough before hardening the rules. The test there is the same command now living on your CLAUDE.md first line.

Safe configuration is no one-time chore. It wants one short review weekly at the start, because your repertoire grows and the list must follow. Reserve two minutes, open /permissions, and read each item out loud. For every line, ask whether it really needs to run silently.

Promote a command from ask to allow only once it meets three conditions together. It repeats nearly daily, its effect stays within reading or validation, and approving it never scared you. Typical early movers are running the test suite and viewing the diff. The reverse counts on the spot too: if a command gave you a chill, drop it back to ask or deny without debate.

Well-built requests cut repeated questions and bulky diffs. Every strong request carries three short parts: where, what, and how to check. Where points at the folder or file. What describes the change in one sentence. How to check names the read or test proving it worked. That shape opens the read-before-edit cycle in the getting-started guide, Apr 8, 2026.

Use these two literal templates day to day:

In this folder, explain which files handle login, without changing anything.

In this file, adjust this help text and show the diff before finishing.

The guard sits at each sentence's end. Without changing anything holds the agent in reading mode. Show the diff before finishing demands proof before done. When the agent asks back, answer short with the file name and the expected result. Good answers produce right changes on the first try.

Some keys remove every lock at once and make sense only in a disposable folder. The names to remember are bypassPermissions and the --dangerously-skip-permissions flag. Outside a test folder you can delete without loss, keep those options off.

Freeing everything to move faster ranks among the central mistakes in the 3 stumbles from the Apr 27, 2026 complete getting-started guide. The shortcut looks productive because confirmations vanish. The bill arrives later, when a command reaches .env, deletes files, or force-pushes code with no review pause.

Take this working rule to never fall for the shortcut. In the real project, always run in plan or with asks on. In a disposable training folder, you may test one specific command with fewer locks to learn the effect, then delete the folder. That split keeps curiosity without exposing real work.

If you already freed everything once, return to safe in three steps. First, switch plan back on in /permissions. Second, confirm .env reads, rm -rf, and force push sit in deny. Third, open CLAUDE.md and confirm the test command plus limits are still there. Then request one small chore to feel the rhythm with locks on.

To place that lock inside the broader tool picture, save this shortcut for after setup: Claude Code vs Cursor vs Copilot.

What is the first useful line of CLAUDE.md?

Your project's test command. It tells the agent how to prove a change works before finishing. In this guide's template, that line is npm test under How to validate. That first-line-with-tests role is in the Apr 27, 2026 complete getting-started guide. Swap in your setting's real command and keep the rest short.

When may I move a command from ask to allow?

Once it repeats, stays bounded, and never raised a doubt at approval. Reading with Read and Grep, checking with git status and git diff, and validating with npm test tend to migrate first. Editing with Edit and shipping with git commit and git push should stay in ask longer. In doubt, hold it in ask one more week.

May I use bypassPermissions to move faster?

Avoid it in the real project. Those keys remove the pauses guarding secrets and destructive commands. Use them only in a disposable folder you can delete without loss, to learn one specific command's effect. In real work, the speed gain never pays for the risk of exposing .env or deleting files.

How often should I review permissions?

Weekly at the start. Open /permissions, read each item, and ask whether it needs to run silently. Promote to allow only what repeats safely, and pull back to ask or deny everything that raised a doubt. That short review holds the list aligned with your repertoire and stops an old grant from turning into a new risk.

Safe setup comes down to four moves in order. Turn on plan permission mode, copy the allow, ask, deny list with .env locked, keep CLAUDE.md short with a test command and limits, and review /permissions weekly. That set removes the mistakes that scare beginners most and leaves the diff as proof of each step.

When doubt hits mid-chore, return to the good request's three questions. Where am I, what do I want to change, how will I check. If the answers fit short sentences, the request is ready. If any answer stays vague, ask for an explanation before asking for a change.

Move on in this order. Revisit the guided drill in first-30-minutes walkthrough to reinforce the diff-with-tests cycle. Then compare tools in Claude Code vs Cursor vs Copilot only after locking this guide's base.

• getting-started guide
• complete getting-started guide
• beginner tutorial