Setting it up safely.

An agent that can edit your code and run commands is powerful, and power in a codebase wants guardrails. The good news is the safe setup is mostly things you already believe in: tight scope, good context, least privilege, and a green pipeline before anything merges. The piece that's new with Claude Code is the permission dial, which puts you in control of every action. Here's how it all comes together.

Permissions: your dial for what it can do

This is the heart of using it safely, so start here. Claude Code asks for approval on actions according to your permission settings. You decide what it can read, run and edit, and which actions it has to clear with you first. Reading a file is harmless and runs freely. Running a command or changing a file is where it pauses and asks, unless you've told it otherwise. You can tune that with allow and deny rules and permission modes: tighten it right down so every action needs a yes, or, once you trust a pattern, let routine moves through while still gating the risky ones.

• Approve as it goes. The default, and the right place to start: you see each action before it happens and wave it through or stop it. Slower, but you learn exactly how the agent works.
• Allow and deny rules. Pre-approve the safe, repetitive things (running the test suite, say) and hard-block the ones you never want it touching. Less prompting, with the dangerous moves still fenced off.
• Looser modes, used carefully. There are modes that auto-accept more so the agent can run with less interruption. Reach for those only on low-risk work, in a contained setup, once you trust the pattern, never as the day-one default on anything that matters.

The principle underneath all of it: grant the least the task needs, and keep a yes in front of anything that could do real damage.

Give it the context a new hire would need

The agent only knows what's in the repo and what you tell it. So treat it like a sharp new starter on day one: capable, but blank on your conventions. Claude Code reads a project instructions file, a CLAUDE.md in your repo, and loads it with every session. You don't have to write it from a blank page: run /init and it reads the project and drafts a first CLAUDE.md for you to tidy. That file is the place for what a new engineer would otherwise have to absorb:

• How to run the build, the tests and the linter.
• The conventions you actually care about: structure, naming, the patterns to follow and the ones to avoid.
• Anything load-bearing and non-obvious, the gotchas that trip people up.

A good instructions file is the highest-leverage thing you can do. Time spent here pays off on every task afterwards, the same way good onboarding docs pay off with every hire. It's also a hierarchy: a user-level file in your home folder carries your personal preferences across every project, and a nested CLAUDE.md deeper in the tree can add rules that only apply to that part of the codebase. If you already keep conventions in another file, you can point the instructions file at it rather than writing them twice.

Start small, in a branch or sandbox

Don't begin with a high-stakes change to your core system. Begin where a mistake is cheap and easy to spot, and let trust build from there:

• Work on a branch, never straight on main. Have it make changes on a feature branch so nothing lands on your main line without review. The cloud option keeps work off your machine entirely, which is another clean way to contain it.
• Read-only or analysis first. Ask it to explain a module, find where something is handled, or propose an approach, before you let it write anything. Plan mode is built for exactly this: it explores and lays out a plan without touching a single file, so you approve the approach before any change happens.
• Then low-risk changes. Add a test, tidy a function, fix a small bug with clear reproduction steps. Keep approvals on and watch how it works and how it reasons.
• Widen as it earns it. Once you trust the pattern on small jobs, loosen the permissions a notch and hand it larger, still-well-scoped ones. Trust and access expand together, never ahead of each other.

Review every change, with CI as the backstop

Two safety nets sit under all of this, and neither is optional. The first is you: read every change the agent makes before it goes anywhere, the same way you'd review a teammate's work. We give review its own lesson, because it's the habit that matters most. The second is your pipeline. Have the agent work on a branch and open a pull request, and your existing protections catch it like they catch everyone else: protected branches stop anything landing on main without passing the gates, required status checks mean the tests and linters have to be green, and required reviews mean a human signs off before merge. None of this is agent-specific, and that's exactly why it works. If your branch protection and CI are solid, you've done most of the safety work already. If they're thin, shore them up before you lean on an agent, because they're the floor under everything else.