Claude Code permissions for beginners: start with one change

Claude Code is most useful when you let the agent do real work, but keep the decision points visible. After the first guide, where Claude Code read the project before changing anything, the next habit is simple: ask for a plan, approve one bounded change, review the diff, and save a run receipt.

This is not a security manual. It is a working routine for using a coding agent without clicking through permission prompts on autopilot.

Who this guide is for

This is for you if you have tried Claude Code for beginners: let the agent read the project first, or if you can already open a project in Claude Code. You might have a website folder, a script, a course project, or an internal demo where you want the agent to help with one clear change.

The goal is not to block Claude Code from everything. The goal is to give the agent the right access for an understandable task and keep a receipt of what actually happened.

What you will learn in 10–20 minutes

• What Claude Code permissions mean in practice.
• When Plan mode or a plan-first prompt is the right starting point.
• How to read a permission prompt like a work order.
• How to approve one change, review the diff, and run a check.
• How to save a short run receipt.

Where to start

If Claude Code is not installed yet, start with the first guide in the series. This continuation assumes you can open a project.

Start here:

1. Open a copy, branch, or demo folder where a first change is acceptable.
2. Start Claude Code in the project folder with claude, or use Claude Code in VS Code if that is your normal setup.
3. If you want a controlled CLI start, use claude --permission-mode plan.
4. During a CLI session, Shift+Tab can switch permission modes.

The Claude Code documentation describes permission modes as different levels for how the agent may read, plan, edit, and run commands. In default, Claude asks before file edits and non-read-only commands. In plan, it can explore and propose without changing source files.

Source: Claude Code permission modes, Claude Code common workflows

What do permissions mean in plain language?

Claude Code permissions are the rules around what the agent may do in your project: read files, edit files, run commands, or use tools. Reading and searching are usually lower drama. File edits, Bash commands, network access, new dependencies, and access outside the project folder deserve more attention.

One detail matters: permissions are enforced by Claude Code, not by polite wording in your prompt. You can write "do not touch .env", and that is still sensible. But real access control belongs in permission modes, /permissions, project-folder boundaries, secret managers, scoped API keys, and clear approvals.

Source: Claude Code permissions, Claude Code security

Before the first approval

Make the agent useful, but define the playing field.

• Work in a branch, copy, or demo folder.
• Keep secrets in .env, secret managers, or environment variables, and do not paste them into prompts.
• Keep the first task inside the project folder.
• Ask for an explanation before network access, parent folders, new dependencies, deployment commands, or destructive Git commands.
• Do not use bypassPermissions as the beginner choice on a local work folder.

This is integration work, not fear. You give the agent enough access to help and let every decision leave evidence.

Step by step: plan, approval, diff, and run receipt

Step 1: ask for a plan before editing

Paste this before Claude Code changes files:

Before editing anything, make a short plan for one bounded change.

Goal: [describe one improvement]

Tell me:
1. which files you need to inspect,
2. which files you propose to change,
3. whether any command, network access, new dependency, or secret is needed,
4. how we will verify the result.

Do not edit files yet.

If the plan feels too broad, answer:

Make this narrower. Choose one reversible change that touches as few files as possible.
Avoid secrets, .env files, deployment settings, package-manager settings, unrelated refactors, and new dependencies.

Step 2: read the permission prompt like a work order

Ask yourself:

• Is the requested action exactly what you asked for?
• Is the file path expected?
• Is it inside the project folder or copy?
• Is the command a check, such as npm test, npm run build, or git diff, or does it change something?
• Is it asking for network access, deployment, credentials, or new dependencies that this task does not need?

If something feels off, ask Claude to explain why the action is needed or narrow the scope.

Step 3: approve only the bounded action

When the plan and prompt match, approve it. Stay with one change. If the agent starts touching unrelated files, stop and ask it to summarize or revert.

In VS Code, you can often review changes side by side. In the terminal, git diff gets you far.

Source: Claude Code IDE integrations, Claude Code best practices

Step 4: ask for the diff and evidence

After the approved change, use this prompt:

Summarize exactly what changed.
Show me:
1. changed files,
2. the important diff in plain language,
3. any commands you ran and their results,
4. what still needs human review.
Do not make more changes unless I approve them.

Step 5: run one check before keeping it

Choose a check that fits the project:

• a test command if the project has tests,
• build, lint, or type check if available,
• local preview for a text or website change,
• a manual checklist if the project has no automated tests.

A coding agent should not leave only a feeling that something improved. It should leave evidence: what changed, which check ran, and what still needs human judgment.

Reusable permission-card prompt

Save this as your starting prompt for a controlled Claude Code session:

You are helping me with one controlled Claude Code change.

Rules:
- Plan before editing.
- Touch only the files needed for this change.
- Do not read or edit .env files, secrets, deployment settings, package-manager settings, or unrelated files.
- Ask before network access, parent folders, new dependencies, destructive Git commands, or production-like commands.
- After an approved edit, summarize the diff and tell me exactly how to verify the result.
- Mark anything uncertain as "needs human review".

Task:
[describe one bounded change]

And save this run receipt afterward:

Claude Code run receipt
- Goal:
- Approved action:
- Files changed:
- Check run:
- Result:
- Needs human review:
- Decision: keep / revert

Common mistakes

• Treating the permission prompt as a formality.
• Starting in acceptEdits, auto, or bypassPermissions before you have a review habit.
• Asking for a broad refactor when you need one clear change.
• Approving network access, deployment, new dependencies, or credentials without a reason.
• Forgetting to inspect the diff.
• Keeping the change without a test, build, preview, or manual check.
• Thinking prompt rules replace real permission rules.

Next step

If this routine works, make it your Claude Code default: plan first, clear approval, diff review, a check, and a run receipt. Later you can build on it with CLAUDE.md, durable project rules, hooks, MCP, subagents, or background jobs.

If you want to test coding agents in a team, school, or business without losing visibility, Hammer can help choose the first workflow, set clear permissions, and build a habit around plan, diff, tests, and human review.