Claude Code for business teams: setup, guardrails and what it is good for

Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands and integrates with your development tools. It runs in a terminal, in IDE extensions, in a desktop app and in a browser, and the same project files (CLAUDE.md, settings, MCP servers) apply across them. It works directly with git: it can stage changes, write commit messages, create branches and open pull requests, and it can run in CI through GitHub Actions or GitLab CI/CD.

It is not autocomplete, and it is not a replacement for someone on your team who can read a diff. Speed you cannot review is a faster way to build something you cannot maintain. We use Claude Code day to day and we build on Claude through its public API. We are not an Anthropic partner, and nothing here is endorsed by Anthropic.

Everything below about the tool's behaviour comes from Anthropic's Claude Code documentation, as we read it on 10 October 2026, and is linked under Sources. The product changes often, so check those pages before you rely on a detail.

Put the safe way of working in the repository so nobody has to remember it. Six layers do that, and they are not equally strong. Only some of them are enforced.

CLAUDE.md: the brief

CLAUDE.md is a markdown file Claude Code reads at the start of every session. A project file lives at ./CLAUDE.md or ./.claude/CLAUDE.md and is shared through version control; a personal CLAUDE.local.md is meant to be added to .gitignore; an organisation can deploy a managed file to every machine. The documentation recommends concrete, checkable instructions and a file under 200 lines, with longer or area-specific guidance moved into path-scoped rules under .claude/rules/. Running /init generates a starting file. Add a line whenever Claude repeats a mistake or a code review catches something it should have known.

For an operations codebase, the lines worth writing are the ones a new contributor would otherwise get wrong. These are examples to adapt, not a template from the documentation.

• Run the lint, type-check and test commands, and report the result, before calling a change done.
• Never edit a migration that has been applied. Add a new one.
• Billing, permission and role logic lives in named modules. Changes there need a test that a person has written or approved first.
• Never read or print environment files. Nothing in this repository should point at production.
• Retries must be safe to repeat: use a stable key and find-or-create, not a blind insert.

Permissions and modes: what runs without asking

Anthropic's security page describes the choices. In manual mode Claude Code starts read-only and asks before editing files or running commands, apart from a built-in set of read-only commands. Accept Edits mode auto-approves file edits and a fixed set of filesystem commands inside the working directory. Auto mode uses a separate classifier model to approve or block actions instead of a person, and the page describes it as the built-in starting mode for interactive terminal and VS Code sessions. Check which mode your version and surface start in, and choose the team's default on purpose rather than by accident.

The shared file is .claude/settings.json, committed so everyone who clones the repository gets the same rules. The documentation's own example allows the lint and test commands and denies reading .env files. Three details matter for teams. Allow rules in a committed file apply only after each person trusts the folder, while deny and ask rules apply straight away, so a committed deny list is safe to rely on. Allow lists from different files are combined, not replaced. And the auto and bypassPermissions default modes do not take effect from project or local settings, so a repository cannot switch the prompts off for everybody who opens it.

A permission prompt is not a sandbox. The documentation is explicit that the working-directory boundary is a prompt, and that a Bash command you approve can still write anywhere your user account can. For real isolation it describes a sandboxed bash tool with filesystem and network isolation, configured with /sandbox, and development containers. A deny rule on a command also matches the command as written, so network enforcement needs the sandbox. Organisations can enforce settings centrally through managed settings. Above all, keep production credentials off the machine that runs the tool.

Hooks: checks that do not depend on the model remembering

Hooks are user-defined shell commands, HTTP endpoints or prompts that run automatically at set points in Claude Code's lifecycle. The documentation's examples are the useful ones: a PostToolUse hook that runs a lint script whenever Claude edits or writes a file, and a PreToolUse hook that blocks destructive shell commands. A hook that exits with code 2 blocks the action.

Three cautions from the same documentation. Command hooks execute with your full user permissions, so review them like code. Any other failure, such as a script path that does not exist, is a non-blocking error and the action goes ahead, unless you set the hook to block on failure. And in an interactive session hooks wait for workspace trust, but a non-interactive claude -p run treats the folder as trusted, so hooks committed in a repository run. Review the .claude directory before scripting Claude Code over a branch you did not write. Hooks speed up the loop. They are not your last line of defence.

MCP servers: connect read-only, and to staging

The Model Context Protocol is an open standard for connecting AI tools to external data and services, and Claude Code can use it to reach tickets, documents or your own tooling. Project servers are defined in .mcp.json, which can be committed. The security page adds that servers at other scopes, claude.ai connectors and plugins are configured outside the repository, so reading .mcp.json does not show every server a session can load. It also says Anthropic does not security-audit or manage MCP servers, and encourages writing your own or using providers you trust.

For an operations team that means a database connection to staging, read-only, and nothing that can send, pay or delete. An assistant connected to the live system with write access moves from the first class of risk to the second, the same line our article on AI agents for operations draws.

Tests and CI: the safety net that is not the tool

Claude Code can run your tests locally and fix what fails, and that is useful. But the gate that counts is the one that runs on a clean machine for every pull request: lint, types, tests. Before changing inherited code, have the tool write characterisation tests that pin down what it does today, and run them first. Beware the green tick the tool earned by writing tests to match its own code. For billing and permission paths, a person states the expected outcomes first.

Claude Code can also review pull requests and triage issues in CI. Treat that as an extra reader. It does not replace the human one.

Branch protection and human review

Configure the repository so the main branch accepts changes only through a pull request, with the required checks passing and an approving review from someone who is not the author. Use code-owner rules, where your host offers them, for directories that hold money, permission and migration logic. One detail from Anthropic's security page applies to cloud sessions: GitHub decides which branches a session can update by applying your branch protection to the access you connected, and a rule that access can bypass does not block a session's push. Do not connect an identity that can bypass your own rules.

It is best at work where the pattern already exists and the result can be checked by running it. It is weakest where the hard part is knowing a business rule, because nobody has written that down for it either.

The common thread is that someone already knows what 'correct' looks like and can check it quickly. The trading ERP we built shows the other side of the line: its money and audit rules live in the database, not in anyone's judgement, and that is the kind of code where we would not let any assistant make a change without a person writing the tests first.

The failure has a recognisable shape: a large diff, green tests that the tool wrote to match its own code, and a reviewer who skims because the checks passed. It is worst in money, permission and migration code. These controls break the chain.

1. 01Ask for one thing at a time, so each change is small enough to read in one sitting.
2. 02For money, permission and migration logic, a person writes or approves the tests before the change is made.
3. 03The person who gave the instruction reads the whole diff before asking anyone else to. Two readers, not one.
4. 04Require an approving review at the code host. Nobody approves their own change, and the checks must pass.
5. 05Have the pull request say what changed, what was run, and what was not checked. Ask Claude to explain the diff if it helps, but never accept the explanation instead of reading.
6. 06Give extra scrutiny to changes that edit the guardrails: .claude settings, hooks, CI configuration, branch rules. Anthropic's security page suggests auditing or blocking settings changes during a session with ConfigChange hooks.
7. 07Watch for deleted tests, loosened assertions and new dependencies, and from time to time ask a reviewer to explain a merged change without looking at it.

Cost and data handling. Anthropic's overview says most Claude Code surfaces require a Claude subscription or an Anthropic Console account, with some also supporting third-party providers, so usage has a bill. Set a budget and do not rely on a figure in an article. Before you use it on a codebase that contains client data, read the data and privacy terms for your plan, because they differ between consumer, team and API use.

Prompt injection. Claude Code reads files, web content and tool results, and any of them can contain text that tries to give it instructions. Anthropic's guidance is to review suggested commands, avoid piping untrusted content straight in, verify proposed changes to critical files and consider virtual machines for risky work, and it says no system is immune. The controls above limit the damage but do not remove the risk.

Our own evidence. We use Claude Code ourselves, and the school ERP case study describes a build done with it and reviewed by seven read-only agents. The only Claude production system in our case studies is invoice reading on the trading ERP. We have not published a case study of rolling Claude Code out to a client team, so this is a recommended setup from the documentation and our own practice, not a measured result. Our Claude platform page sets out the same position, and our Claude Code development page describes what we offer.