Using Claude Code

Claude Code does not run one command and stop. It runs a loop: it reads files, proposes a change, edits code, runs the build or the tests, reads the output, and decides what to do next. That autonomy is the point, and it is also the risk. The same agent that can fix a failing test across four files unattended can also run a command you did not read, or rewrite a module you never asked it to touch.

Picture the expensive version of learning this. A developer fires up Claude Code on a real repository, types "clean up the auth module and make the tests pass", and starts approving prompts to keep momentum. Around the eighth approval the prompts blur together. One of them is a Bash command that deletes a directory of generated files the build depends on. They approve it without reading. Now the tests fail for a new reason, the agent tries to "fix" the failure it caused, and twenty minutes later the working tree is a tangle nobody can cleanly revert. The model did exactly what an agent does. It predicted a plausible next action and asked permission, and the permission was granted on reflex.

The cost is rarely the single bad command. It is the loss of a clean diff to review. Once an agent has made fifteen edits and run ten commands in one drifting session, you can no longer tell which change was the one you wanted and which was the cleanup of its own mistake. The review that should take five minutes becomes an archaeology dig.

Getting this right is concrete and learnable. The agent predicts plausible output from what is in its context, and plausible is the dangerous kind, because it looks right until you check it. Your leverage is three gates the tool gives you for free: the context you supply before it starts, the plan you agree before it writes, and the permission prompt and diff you read before you keep anything. The mechanism that makes those gates work is the permission system and plan mode, which the next section breaks down.

Claude Code is an agentic loop wrapped in a permission system. Naming the parts shows you exactly where to stand to keep control.

• The loop. Read, plan, edit, run, react. Claude reads the relevant files, proposes a step, makes an edit or runs a command, observes the result, then reacts to it. Every edit and every command is a place it pauses for you.
• Permission rules. In settings.json, tools are sorted into allow, ask, and deny lists. The rules evaluate in deny, then ask, then allow order, so a deny rule wins over any allow. A rule like Bash(rm -rf:*) in deny is a hard guarantee the prompt instruction "be careful with deletes" can never be.
• Permission modes. The mode sets the baseline for how often the loop pauses. There are six: default (reads run freely, everything else prompts), acceptEdits (file edits and common filesystem commands run without asking), plan (read-only exploration), auto (a separate classifier model vets each action and blocks anything that escalates), dontAsk (only pre-approved tools run, the rest are denied), and bypassPermissions (no prompts at all).
• Protected paths. In every mode except bypassPermissions, writes to a small set of paths such as .git, .claude, and your shell config are never auto-approved, even if an allow rule seems to cover them. This guards your repository state and Claude's own configuration from an accidental overwrite.

The distinction that decides whether a session stays safe is plan versus build. Plan mode tells Claude to research and propose without editing your source. You enter it with Shift+Tab, by prefixing one prompt with /plan, or by launching claude --permission-mode plan. In plan mode Claude often spins up a built-in Explore subagent to read widely in its own context, then returns a written plan. You read it, edit it directly with Ctrl+G if the approach is wrong, and only then approve. Approving the plan is the moment you switch the session into a build mode and the editing starts.

One nuance that catches people: a subagent runs in its own separate context window. A foreground subagent passes its permission prompts through to you as they come up. A background subagent prompts once for the tools it will need before it launches, then runs with those permissions and auto-denies anything else that would otherwise prompt, so a write it did not clear up front silently fails rather than pausing for you. The practical rule is to keep wide-reaching exploration in read-only subagents and let the parent session, where you can see every prompt, own the edits and the risky commands. With the parts named, the next section walks one task through the whole loop.

Maya, a developer, needs to add a logout() helper to an existing auth module in a real repository. The helper should clear the session and redirect to /login, and it needs a test. She has used Claude Code before and been burned by a drifting session, so this time she works the three gates deliberately.

1. Set the context. The repo already has a CLAUDE.md at the root that says the package manager is pnpm, that auth lives in src/auth/, and that src/generated/ is off limits. That file loads automatically at session start, so Maya does not retype any of it.
2. Scope the prompt. She types one outcome, not a wish list: "In src/auth/, add a logout() helper that clears the session and redirects to /login. Write a test in src/auth/logout.test.ts for the logged-out case. Plan it first, then run the test suite, then show me the diff."
3. Plan first. She presses Shift+Tab into plan mode. Claude reads src/auth/session.ts and the existing tests through an Explore subagent and returns a four-step plan. The plan proposes touching src/auth/index.ts to re-export the helper, which Maya did not want yet. She opens the plan with Ctrl+G and deletes that step.
4. Approve to review-each-edit. She approves the edited plan with the option to review each edit manually rather than the auto option. The session leaves plan mode and starts editing under close watch.
5. Approve deliberately. Two write prompts appear, one for the helper and one for the test. She reads each diff and approves. A Bash prompt to run pnpm test appears. She reads the command, confirms it is the test runner and not something else, and approves.
6. Verify and commit. The suite reports 14 passing tests, up from 13. Maya reads the final diff: two files changed, 23 lines added, nothing in src/generated/. She commits with a one-line message, then runs /clear before her next task so the context does not carry over.

The whole change took one focused session and left a clean two-file diff she could review in two minutes. The difference from the drifting version is that every gate was read, not skipped, and the context never filled with unrelated work. Maya carries into the next section, because the gates that worked here are exactly the ones people are tempted to remove.

Each of these traps feels like it speeds you up, and each quietly removes the gate that was keeping you safe.

• Reflex approval. After a run of harmless prompts, you stop reading and start approving. The fix is to keep default mode for unfamiliar work so reads run free while edits and commands still pause, and to actually read the Bash command in each prompt. If a class of command is genuinely safe and frequent, encode it as an allow rule once rather than approving it by hand fifty times.
• Reaching for bypass to stop the noise. The prompts get annoying, so you launch with --dangerously-skip-permissions on your real machine. Now there is no gate at all, and prompt injection from a file or web page has nothing standing in its way. If you need fewer prompts, use auto mode, where a classifier still blocks escalations, or pre-approve the specific safe tools. Save bypassPermissions for an isolated container or VM.
• The sprawling session. One session for "refactor auth, fix the flaky test, and update the docs" fills the context with three jobs at once, and the edits for one bleed into another. Run /clear between unrelated tasks so each starts from a clean window.
• Building without a plan. A vague request straight into a build mode lets the agent guess the approach, and you end up reviewing a large diff founded on the wrong assumption. Plan first for anything beyond a one-line fix, and edit the plan before you approve it.

Two genuine edge cases sit underneath those traps. The protected path that looks allowed. You add Edit(.claude/**) to your allow rules expecting Claude to manage its own settings, and it still prompts. That is by design: the protected-path check runs before allow rules are evaluated, so writes to .git, .claude, and similar paths stay gated in every mode but bypassPermissions. Treat the prompt as a feature, not a bug.

The large diff that outpaces your review. A 2026-specific wrinkle: an agent can generate a plausible 600-line change faster than you can read it, and review capacity, not code volume, is now the bottleneck. A diff that big invites rubber-stamping. The handling is to keep each task small enough that its diff fits under roughly 400 lines, which is also where review cycles run noticeably faster, and to lean on the plan to split a big change into reviewable steps. Keeping diffs small matters even more once more than one person shares the repo, which is where scale comes in.

A single developer can hold their own habits in their head. The moment a team shares a repo, the settings and the conventions have to live in versioned files, or every person re-learns the same lesson and the agent behaves differently for each of them.

The durable artifacts are checked into the repo. A root CLAUDE.md records the conventions Claude reads at every session start: the package manager, the test command, which directories are off limits, the "always do X" rules. Keep it under about 200 lines and move longer reference material into skills, because a bloated CLAUDE.md spends context on every request and starts to drift. Project-level settings.json holds the shared allow, ask, and deny rules, so a deny on Bash(rm -rf:*) protects everyone, not just whoever remembered to set it. For hard guarantees that a rule holds every time, a PreToolUse hook that blocks a command is enforcement, where a line in CLAUDE.md is only a request the model can reason around.

Priya, who leads the team, packages the shared setup so nobody assembles it by hand. A plugin bundles skills, subagents, hooks, and MCP servers into one installable unit, and a marketplace distributes it. She publishes a marketplace.json catalog to a git repo, and teammates run /plugin marketplace add with the repo, then install the team plugin from it. Updating the plugin is a push to the repo and a /plugin marketplace update on each machine. The same review discipline applies to what gets installed: a plugin can run hooks and connect MCP servers, so the team reviews a marketplace before trusting it the way they would review any dependency.

Scale also changes how the work is recorded. Priya's team writes the agent's role and the prompt into the pull request description, so a reviewer knows a change was AI-drafted and what it was asked to do, and they hold AI-drafted PRs to the same small-diff bar as any other. Automated linters and scanners in CI catch a large share of routine issues before a human looks, which frees the human review for the assumptions the agent made, the question being "what is this code assuming, and is that safe?" rather than "does this look reasonable?".

The durable principle to keep, whatever the size of the team, is that the agent proposes and your gates decide. Supply the context, agree the plan, read the diff, and never trade all three away for fewer prompts on a machine you care about. Start with one small thing: write a short CLAUDE.md for one repo and run your next task in plan mode. Add the rest, the deny rules, the hooks, the plugin, one trigger at a time as the habit holds.