Trust Claude. But verify the important stuff.
Claude Code can read files, edit them, and run commands in the environment you give it. That is why it is useful, and why a good prompt is not your safety control.
My project instructions say never to commit .env files. I still check before publishing. I also save a checkpoint before structural changes. It costs me seconds and has saved me hours.
My rule is simple. Limit the scope, check the change, test it, and keep a way back.
Check the permission mode first
The permission mode decides how often Claude stops to ask. It is the first thing to check, because it changes what a careless prompt can do.
| Mode | Runs without asking | Use it for |
|---|---|---|
Manual (default) |
Reads only | Learning, and anything sensitive |
acceptEdits |
Reads, file edits, common file commands | Iterating on changes you are reviewing |
plan |
Reads, plus proposing an approach | Exploring before you change anything |
auto |
Everything, with background safety checks | Long tasks, when you accept less oversight |
dontAsk |
Only tools you pre-approved | Scripted and locked-down runs |
bypassPermissions |
Everything | Isolated containers and virtual machines only |
Shift+Tab cycles Manual, acceptEdits, and plan in the CLI, plus any other mode you have enabled. The status line under the input shows which one is active. Other Claude Code surfaces use a mode selector.
Stay in Manual mode while you are learning. The last two rows are not beginner settings, and bypassPermissions belongs on a machine you would not mind rebuilding.
For a structural change, enter Plan mode with /plan or cycle to it with Shift+Tab. Plan mode lets Claude inspect the project and propose an approach without editing source files.
I use it when the task touches several files or changes the project structure. My prompt is usually close to this:
Explain the approach, files you expect to change, risks, and checks.
Do not edit anything yet.Review the proposal before switching to an editing mode. A sensible plan does not guarantee a safe implementation, but it catches a wrong direction before files move.
Anthropic documents the current behavior in Claude Code permission modes.
Instructions are not enforcement
Put project rules in CLAUDE.md so Claude sees your intent. For example:
## Sensitive files
- Never read, display, edit, or commit .env files
- Never put credentials or customer data in source files
- Ask before changing authentication or deployment configurationThis helps Claude follow the rules, but it does not protect the files. Instructions are context, and context can lose an argument with a confident plan.
When something must never happen, use a control the client enforces rather than one Claude interprets:
- Deny rules in your settings block a tool, command, or path outright, in every mode. This is the real answer to the
.envexample above. - Hooks run your own shell command at a fixed point, such as before every tool call, and can refuse the action regardless of what Claude decided.
/security-reviewchecks the current changes for vulnerabilities before you ship them. Worth running on anything that handles input, authentication, or money.
Rules in CLAUDE.md express intent. Deny rules and hooks express a limit. Use the first for the hundred small conventions and the second for the two or three things that would actually hurt.
Keep secrets outside the repository, ignore local configuration, and limit which credentials are available to the session. Before a push, inspect the exact staged files:
git diff --cachedConfirm that .env, local settings, exported data, and generated credentials are not included. Use secret scanning or repository push protection when available.
If a real credential was already pushed, rotate or revoke it first. Removing the text from Git history does not make the old credential safe. GitHub's sensitive-data guidance covers the recovery order.
Let the operating system hold the boundary
Approving each command works while you are learning, but it wears thin. Claude Code has a sandbox for the Bash tool that changes the deal: instead of approving commands one at a time, you decide once which files and which network domains commands may touch, and the operating system enforces it for every command and anything it starts.
Open it with:
/sandboxThe panel tells you what is available on your machine and what is missing. It runs on macOS, Linux, and WSL2. Native Windows is not supported, so on Windows this means running Claude Code inside WSL2.
What you gain is a boundary that stops depending on you reading every command carefully at the end of a long session. Fewer prompts is the side effect.
Review the change, not the promise
When Claude says a task is complete, inspect what changed.
For a small visual adjustment, open the page at the relevant width. For a code change, run the existing tests and read the diff. For a configuration change, confirm the exact keys and environment it affects.
If you do not understand part of the diff, ask:
Explain this change in plain English, including what could break.
Do not make another edit.The explanation can help, but you still need to test the change.
Specificity reduces the chance that Claude changes the wrong thing. It does not make a change safe. “Remove the gap between the footer links and copyright text” is better than “clean up the footer,” but I still review the diff and open the page.
Keep separate recovery layers
Save a local checkpoint before a risky edit, commit a known-good version when using Git, and keep an off-device copy for disk loss. Each one protects you from a different problem.
A checkpoint helps undo the last agent change. Git explains what changed across versions. An off-device copy protects you when the computer or disk is gone.
One backup file beside the project does not cover all three.
Start a fresh session when the task changes
Long conversations collect decisions, failed attempts, and instructions from earlier work. When the task changes, that context can pull the next answer in the wrong direction.
I use one task per session as a default. A new session reloads project instructions and drops the previous conversation. Claude then searches and reads the files needed for the new task. It does not scan every file in the project automatically.
The current instruction-loading behavior is documented in Claude Code memory.
Start a new session when:
- you move to an unrelated task
- Claude keeps repeating an approach you rejected
- old requirements conflict with the current work
- you want a clean review of the result
Review what you publish
The .claude directory is not automatically secret. Shared project rules may be safe and useful to publish. Local settings, hooks, prompts, and examples can still reveal home-directory paths, internal systems, or client details.
Review it like any other directory. Before publishing, I check the exact staged files. The folder name and Claude's confirmation are not enough.
When Claude is wrong
Test the behavior first. If it fails, give Claude the exact result, error, and reproduction step. If the same approach keeps failing, restore the known-good state and start a new session with the evidence you now have.
Do not let five speculative fixes accumulate. One change, one check. That keeps the failure understandable.
Claude's capability and your judgment work well together. Remove the review and recovery layer, and you are only making mistakes faster.
Frequently Asked Questions
Does Claude Code ask permission before every change?
That depends on the permission mode. Manual mode runs reads on its own and asks before other actions unless a permission rule already decides them. acceptEdits also approves file edits and common file commands. bypassPermissions skips most prompts, but explicit ask rules and a few safety checks still apply. The status line under the input shows which mode is active, so check it before you start.
Which permission mode should I use?
Stay in Manual while you are learning, and switch to Plan mode when the task touches several files or changes the project structure. Reserve bypassPermissions for an isolated container or virtual machine you would not mind rebuilding.
Can CLAUDE.md stop Claude Code from touching my .env file?
No. Project instructions tell Claude what you want, but they are not enforcement. A deny rule or a hook can block matching tool calls. If every subprocess must be unable to reach .env, use the sandbox or operating-system permissions, because path rules do not cover every program Claude can run.
How do I check that Claude Code has not staged a secret?
Run git diff --cached before you push and read the exact list of staged files. If a real credential has already been pushed, rotate or revoke it first, because removing the text from Git history does not make the old credential safe.
Is the .claude directory safe to publish?
Not automatically. Shared project rules are often fine to publish, while local settings, hooks, and prompts can expose home-directory paths, internal systems, or client details. Review it like any other directory before it goes public.