The Minimum Claude Code Setup For A Multi-Repository Integration And Infrastructure Estate

Claude Code is easy to install and hard to configure well for a large estate. A team with many repositories of integration workflows and infrastructure code does not need more features. It needs a short list of controls that keep a fast agent from spreading one wrong assumption across every repository at once.

This article describes the smallest configuration that works for that kind of estate. It draws on Sparq's own Claude Code rollout and on client work across integration and infrastructure estates.

Why the estate is the problem

An agent working across many repositories produces a lot of consistent work quickly. Consistency is what makes a wrong assumption expensive. If the agent misreads a naming convention or a field mapping, it applies that misreading everywhere, and it looks correct everywhere.

In the deployment, the requirement shouldn’t be faster typing. It should be a way to change a large integration estate quickly without letting an unreviewed wrong assumption reach every repository. Every control below puts a person, or a hard boundary, where that assumption would otherwise propagate.

The nine pieces of the minimum setup

1. Put the workspace root above all repositories

Launch Claude Code from a directory that contains every repository. Work that crosses repositories, such as changing a shared event schema and the integration workflows that consume it, then happens in one session with one view of the estate. Launching from inside a single repository forces the engineer to stitch together separate sessions by hand.

2. Give each repository its own root-level CLAUDE.md

Repositories in one estate rarely share a runtime, a deployment target, or an audience. One may be integration workflows, another Terraform, another Python on AWS. A single shared instruction file either says too little for each or too much for all.

The pattern that worked is a cascade. A root file loads every time and imports a shared standards hub. Each repository adds its own root-level CLAUDE.md for its runtime, its deployment target and who reads its output. A new engineer and a new agent then onboard through the same material. When you launch above the repos, each repo’s CLAUDE.md loads the first time Claude touches a file there, not at session start.

3. Restrict Claude Code to one MCP server, with change control

Every MCP server is a path for data to enter or leave. Connect Claude Code to one server: a local server over documentation corpus. The restriction is enforced, not just agreed: managed settings lock the MCP list with allowManagedMcpServersOnly set to true and an allowedMcpServers list naming the approved servers, so a server outside the list won’t load. Sparq proposes a change control policy for adding any further server.

Sparq’s own platform runs the same rule. Only the engineers who built the connection layer add new MCP connections, because every new server is a new data path into the system. Either way, the rule is the same: a short, known list, and a process for changing it.

4. Limit writes to two directory trees

A filesystem boundary should let the agent write in two places and nowhere else. The boundary evaluates denies before allows. Two trees is enough for the repositories being changed and a scratch area, and it makes the boundary easy to inspect and explain to a security reviewer.

5. Run subprocesses in an OS-level sandbox

A write boundary that only covers the agent's own file tools does not cover what a shell command can do. Running subprocesses inside an OS-level sandbox applies the same limits to anything the agent launches.

6. Use a command policy that allows inspection and denies mutation

Reading and inspection commands are allowed. Mutating commands and commands that change metadata are denied. This keeps the agent useful for the largest part of the work, which is reading, tracing and proposing, while the actual changes pass through the write boundary and review.

7. Require per-occasion grants for sensitive systems

Some systems should never be open by default. Gate three systems: production, a third-party business system, and the cloud management API. Two details matter. Reads count, so looking at production needs a grant as well as changing it. And a grant is not inherited, so the next task starts without it.

Keep grants in user or local settings, never in the shared project file, so one engineer’s grants never become another’s.

Systems of record, such as an issue tracker, are handled differently. The agent reads them through the tracker’s CLI on a read-only token, not a second MCP server, so it can read freely and can’t write.

8. Give agents no deployment authority

Claude Code writes code and infrastructure definitions. Existing pipelines deploy them by planning on pull requests and applying on merge. No agent holds deployment authority, so nothing the agent produces reaches production without passing the same pipeline and review as human-written changes.

This is the control that most changes the risk profile, and it costs nothing to adopt: the pipelines already exist.

9. Add repository policies, skills and human review gates

The last layer is what sits on top of the boundaries:

• Repository policies. Decisions are recorded in layers (why, what and how), and agent instructions require reading them before changing anything. A role guard can block the implementing agent from editing the decision records. If the agent disagrees with a record, it states which record and why, and the disagreement is logged rather than silently accepted.
• Skills and hooks. A project plugin carries the hooks, skills and agent definitions every seat uses, so each engineer works from the same setup.
• Human review gates. The intended workflow is simple: fill in a form, hand it to Claude Code, review the output. Forms cover intake, adding an event, and architecture decisions. Templates cover CLAUDE.md, README, design and test considerations. The agent states findings in areas it has not covered as hypotheses, marks absence as a gap, and never originates a field mapping.

What this setup does not do

It does not cap usage. The principle behind that is that governance belongs at the point of action, not the point of consumption. Capping how much an agent asks does not make its answers safer. The controls above limit what it can do, and spend is monitored rather than capped.

It also leaves gaps that a real deployment should name. Decide three things up front that teams often leave open: version pinning, who owns updates, and audit logging.

What it looked like in practice

On one client estate, the engineer who did the work both ways assessed change delivery as three to six business days before Claude Code and a few hours after. That is a judgment from the engineer, not a figure pulled from ticket timestamps, and it should be read that way.

Sparq's own rollout is a different shape: four greenfield Python repositories on AWS, used to build the Sparq Agentic Platform, which comprises roughly 34,000 lines of Python across 453 commits and 159 pull requests since May 2026. The same logic applied there: reach systems through a known list of connections, keep changes in pull requests, and keep humans in the review path.

A short checklist

Working with Sparq

Sparq is an Anthropic implementation partner with Claude Certified practitioners, Agent SDK and MCP integration experience, and production-tested patterns from its own engineering practice. If you are planning a Claude Code rollout across a large estate, start with the Anthropic page on teamsparq.com.