How to Use Claude Code in a Team, Not Just on Your Own Laptop

Search for how to use Claude Code and you will find a great deal of good writing, almost all of it answering the same question: how do I, one developer, get more out of this on my own machine. Tips, keyboard shortcuts, prompt patterns, someone's setup after eleven months of heavy use.

None of that is wrong. It is just not the question a team lead asks.

The team questions are: what is this thing allowed to touch, who reviews what it changed, and what stops it doing something irreversible at 5pm on a Friday. Those have precise, documented answers, and they are the least-written-about part of the tool.

First, where it runs

Claude Code is not only a terminal tool, which surprises people who have only seen the CLI. Anthropic's documentation lists it running on the terminal, VS Code, JetBrains IDEs, a desktop app, the web, mobile, a Chrome extension, and inside Slack — plus a computer-use preview and remote control.

This matters for a team more than it does for an individual. It means the surface your developers use and the surface your reviewers use do not have to be the same one. A reviewer who lives in the browser does not need to learn the CLI to see what happened.

Most surfaces need a Claude subscription or an Anthropic Console account. The terminal CLI and VS Code also support third-party providers, which is the route to take if your organisation already routes model traffic through its own gateway.

Permission modes: the part that actually matters

This is the control that decides whether Claude Code is safe to put in front of a team, and it is the thing the personal-setup posts skip.

When Claude wants to edit a file, run a shell command or make a network request, it pauses and asks. Permission modes control how often that pause happens. Anthropic documents six:

• default — reads only. Best for getting started and for sensitive work. Note that this mode is labelled "Manual" in the CLI, the VS Code and JetBrains extensions, and the desktop app. The config value is still default, which is what hooks and SDK integrations use. The manual alias requires Claude Code v2.1.200 or later.
• acceptEdits — reads, file edits, and common filesystem commands like mkdir, touch, mv and cp run without asking. Best for iterating on code you are actively reviewing.
• plan — reads, plus classifier-approved commands where auto mode is available. Best for exploring a codebase before changing anything.
• auto — everything runs, with background safety checks. Best for long tasks where prompt fatigue is the real risk.
• dontAsk — only pre-approved tools run. Built for locked-down CI and scripts.
• bypassPermissions — everything runs. Anthropic's own guidance is isolated containers and VMs only.

In the CLI you cycle modes with Shift+Tab. Other surfaces have a mode selector. Importantly, the mode is set through those controls, not by asking Claude in chat — you cannot talk it into a different permission level, which is exactly the property you want.

The two rules that hold the whole thing together

Rule one: writes to protected paths are never auto-approved. The only exceptions Anthropic documents are bypassPermissions mode and planning sessions where bypass permissions are available. So the mode you pick does not silently open your most sensitive files.

Rule two: modes set a baseline, and permission rules layer on top of it. Deny rules and explicit ask rules apply to every tool. The organisation-level ask setting on connector tools applies. The requiresUserInteraction marker applies.

And the part worth reading twice: those controls apply in every mode, including bypassPermissions. A deny rule still denies in the loosest mode. Allow rules, by contrast, have no effect in bypassPermissions, because everything is already approved.

That asymmetry is the governance model in one line: in the loosest mode you can still forbid things, but you can no longer meaningfully permit them. If you are writing a policy for your team, that sentence is the one to build it around.

Which mode should a team actually default to

Our honest answer, from putting this in front of client engineering teams across Malaysia and Singapore: start at default/Manual, move to acceptEdits once people trust it, and treat auto as a per-task decision rather than a setting anyone leaves on.

The reasoning is not about the tool being dangerous. It is about review debt. A developer running in acceptEdits on a branch they are reading line by line is fine — they are the review. The same developer in auto across forty files at the end of a long day is generating a diff nobody has actually read, and the fact that it was an agent rather than a junior does not change what that costs you three weeks later.

plan is the underrated one. Pointing Claude Code at an unfamiliar codebase in plan mode and asking what it would do — before it does anything — is the single highest-value habit we have seen teams adopt. It surfaces the misunderstanding while it is still free.

bypassPermissions has exactly one correct home, and Anthropic says so plainly: isolated containers and VMs. Not a laptop with production credentials in the environment.

dontAsk is the CI answer

The mode most teams miss is dontAsk — only pre-approved tools run.

This is what you want in automation. A CI job that lets an agent run anything is not a CI job, it is an incident waiting for a trigger. dontAsk inverts the default: nothing runs unless you explicitly allowed it. That is a normal CI security posture and it is the mode that makes agentic automation defensible to whoever signs off on your controls.

What we set on client work

Across the agent builds in our use-case directory, the pattern that has held up is boring and worth copying:

1. Everyone starts in Manual. Not as a training-wheels phase, but until the team can say out loud what the tool is for on their codebase.
2. plan before any unfamiliar change. Read the plan. Argue with it. Then let it run.
3. acceptEdits on a branch, never on main. The branch is the containment.
4. dontAsk everywhere automated, with an explicit allowlist that a human wrote.
5. bypassPermissions only inside a container that has no credentials worth stealing.
6. Deny rules for anything irreversible — they hold in every mode, so they are the one control that cannot be undone by someone cycling Shift+Tab.

None of that is clever. It is the same posture you would apply to a contractor with commit access, which is roughly the right mental model.

The habit that matters more than any setting

Agentic coding tools fail in a specific way: not by doing something obviously wrong, but by doing something plausible that nobody checks. The permission modes are how you decide where the checking happens. They do not remove the need for it.

This is the same argument we make about production agents generally — the model is the small part, and the evaluation harness around it is what decides whether the thing survives contact with a real business. That discipline is written up in our scorecard guide, and it applies to a coding agent as much as to an invoice agent.

If you are also deciding which underlying model to run, we work through that trade-off in Claude Opus 5 vs Sonnet 5 — the short version being that the choice should follow what happens when the model is wrong, not how hard the task looks.

A rollout checklist

For a team adopting this over a fortnight rather than an afternoon:

1. Pick the surfaces. Developers and reviewers do not need the same one.
2. Confirm your CLI version if you want the Manual label and alias — that needs v2.1.200 or later.
3. Set the org-level default to Manual.
4. Write your deny rules first, before anyone starts. They apply in every mode.
5. Decide what "protected paths" means on your repository and check the list.
6. Give everyone one plan-mode session on a real task before they change anything.
7. Move to acceptEdits on branches once the team is asking better questions than the tool is.
8. Automate only in dontAsk, with a written allowlist.
9. Review the diff. Every time. That is the whole job.

The honest summary

Claude Code is straightforward to use alone and genuinely useful. The team version is not harder, but it is a different problem: it is about permission modes, deny rules and where review happens, not about prompting technique.

Get the modes right and the tool becomes something you can defend to a risk function. Leave everyone in auto and you have quietly outsourced code review to nobody.

On accuracy and timing. Permission modes, mode names, version requirements and the protected-path behaviour described here were taken from Anthropic's Claude Code documentation on 11 August 2026. Claude Code ships frequently — check the current docs before writing this into a policy. Anchor Sprint is a member of the Anthropic Claude Partner Network. Claude and Anthropic are trademarks of Anthropic, PBC.