Giving Claude Code Full Repository Context at Enterprise Scale

Claude Code doesn't index your codebase. It reads files, runs grep, and moves through your repo the way an engineer would if they'd just joined the team and had no memory of yesterday. That's the whole story of this piece: at small scale, that design is a feature. At enterprise scale, across a monorepo with a few million tokens, it becomes the reason your agent hands back confident, plausible, and wrong code.

No embeddings store. No stale cache to invalidate. No index that drifts out of sync with the codebase overnight. On a repo with a few thousand lines, that's a genuinely good tradeoff, and it's part of why Claude Code feels fast and honest compared to tools that quietly index and re-index in the background.

The tradeoff breaks down somewhere between 50,000 and 80,000 lines, on a 200K-token context window. Past that point, the agent can't hold a coherent map of the codebase anymore. It stops seeing the whole picture at once rather than getting confused exactly. Larger context windows push that ceiling out, but enterprise monorepos with thousands of files and tens of millions of tokens blow past even the generous versions of that limit.

Every session also starts cold. No memory of the refactor from last week, no awareness that the team already tried the approach it's about to suggest, no sense of the conventions three engineers spent a year establishing. Layer that on top of a phenomenon researchers have started calling context rot: research has found that performance gets less reliable as input length grows. Models don't use a long context window evenly. Content spread across a long context isn't weighted uniformly throughout.

Claude Code isn't limited by the model underneath it. It's limited by what it can reach and hold onto at any one time. Enterprise teams have to build the scaffolding that closes that gap themselves, because the model won't do it for them.

What 89% context loss looks like across distributed services (the enterprise-specific failure mode)

Cross-service refactoring is where this problem stops being theoretical. Change a shared interface and the ripple effects hit five services you didn't open. No single pass through the file system captures that. The agent has to know what it doesn't know it needs to know, which is a strange demand to put on anything.

The numbers get ugly fast. Teams running repositories with 400,000-plus files have seen 89% context loss using conventional 64,000-token windows during exactly this kind of cross-service work. Architectural relationships between distributed services just don't survive being cut off at a window boundary. They're gone, not degraded.

This doesn't look like a crash. There's no error message. The agent gives you a change that looks locally correct, reads clean, passes a glance test, and then quietly breaks something in a service it never looked at. Shallow output dressed up as good output is a lot more dangerous than an obvious failure, because nobody double-checks something that already looks right.

This never appears in a 1,000-line prototype. It appears only once services actually have to talk to each other, which is precisely the condition that defines enterprise software and doesn't exist in a demo.

The instinct to fix this by cramming everything into one giant CLAUDE.md file backfires. A file that starts lean and creeps to 600 lines by month three doesn't help, it actively drags performance down, because it loads in full on every single session whether it's relevant or not. More text isn't more context. Sometimes it's just more noise the agent has to wade through before it gets to the part that matters.

Scale doesn't just mean "throw more tokens at it." It means rethinking how context gets built, scoped, and delivered in the first place.

Context engineering as the discipline enterprise teams are now building around

By mid-2025, engineers deep in this work had figured out that prompt wording wasn't the bottleneck anymore. The real question was different: which files, which tool definitions, which slice of conversation history, which retrieved facts, land in front of the model on any given turn.

Philipp Schmid put a name on it around that time: context engineering, the practice of building dynamic systems that hand a model the right information and the right tools, in the right format, at the right moment, so it can actually do the job in front of it. That's a shift away from treating a prompt as a document you polish once. The context layer becomes something you build and maintain, closer to a piece of software than a memo.

For Claude Code, that system (sometimes called the harness) is made of a handful of concrete pieces: CLAUDE.md files, subdirectory scoping, a map of the codebase, ignore files and permission settings, LSP integration, scoped commands, and sub-agents. None of these are exotic. All of them require someone to actually set them up on purpose.

CLAUDE.md is the piece teams get wrong most often. The pattern that actually holds up over time is layering, not consolidation: a root CLAUDE.md under 100 lines that covers only what's true across the whole repo, with separate CLAUDE.md files inside each service or module scoped to that piece alone. Nobody needs the payments team's quirks loaded into a session working on the notifications service.

LSP integration changes the search primitive entirely. Instead of grepping raw text, the agent navigates by symbol, the same way a senior engineer traces a function call through five files without reading all five files start to finish. It's a smarter kind of laziness, and it works.

Ignore files and permissions matter just as much as the stuff you point Claude toward. Telling the agent what's off-limits, generated code, vendored dependencies, dead branches nobody's deleted, is often more valuable than telling it what to look at, especially in a monorepo where half the files haven't been touched since a reorg two years ago.

And when one context window genuinely isn't enough, sub-agents split the work. Each one holds a scoped slice of the problem, which means the system as a whole has more effective context surface than any single window could offer on its own.

MCP as the connective tissue between Claude Code and the full enterprise knowledge graph

Anthropic announced the Model Context Protocol in November 2024, aimed at a specific headache: before MCP, every tool integration was its own custom connector, built by hand, maintained by hand, broken by hand whenever an API changed upstream.

BCG's framing of the problem is the clean version: without a shared protocol, integration complexity grows quadratically as agents spread across an organization, because every agent needs its own connector to every tool. With MCP, that relationship flattens to linear. One connector, reused everywhere it's needed.

The adoption numbers by mid-2026 back up that this wasn't just a nice idea. Over 10,000 MCP servers running in production. SDKs pulled down more than 97 million times a month. Microsoft folded MCP into Azure AI Foundry Agent Service in May 2025. OpenAI adopted it in March 2025. By July 2026, the protocol moved under the AAIF at the Linux Foundation, with a significant architectural revision. The maintainer list at that point spans Anthropic, Microsoft, OpenAI, Google, and Amazon, which tells you this stopped being one company's side project a while ago.

For Claude Code specifically, MCP connectors reach into Jira, Linear, Confluence, and internal APIs, which is where the reasoning behind a piece of code usually lives. The code tells you what happens. The ticket tells you why anyone bothered.

There's a subtler win buried in here too: writing code that calls tools on demand, instead of loading every tool definition into context upfront, cuts context overhead by up to 98.7%. That matters a lot once an organization has dozens of connected tools instead of three.

MCP isn't a bolt-on feature. It's the piece of architecture that lets context engineering stretch past the repository's edges into the rest of what the company actually knows.

What full codebase context actually enables (the enterprise use cases that only work with it)

Three kinds of work simply don't function without full codebase context, and no amount of clever prompting substitutes for it.

Legacy migration is the first: tracing what calls what across a system nobody fully remembers building, and making a change that holds up everywhere that change reaches, not just in the file it started in. Cross-file debugging is the second: following a bug from where it appears to where it actually started, which often means jumping services, not just jumping files. Meaningful code review is the third: judging a pull request against the conventions the codebase has actually settled into, rather than just reading the diff in isolation.

Spotify's engineers used Claude Code to run fleet-wide code migrations at a pace that wasn't possible before, according to Anthropic's "The Briefing: Enterprise Agents" event in February 2026. That's not a small claim. Fleet-wide migrations are usually the kind of project that eats a quarter and half a team's patience.

Anthropic's enterprise customers, broadly, report cutting time to market for new features from 24 days down to 5, a 79% reduction, and have put substantial volumes of AI-suggested code into production rapidly. Multi-file refactoring and security auditing sit in the same bucket: both demand the agent hold relationships across a system at once, not transform one file and call it done.

The thread running through all of it: the enterprise work that actually moves the needle is cross-boundary work. And cross-boundary work is exactly what context loss eats first.

The enterprise deployment architecture (layers, scoping, and governance that make it production-safe)

Claude Code's attack surface is bigger than a typical SaaS tool's, because it runs locally, in a developer's terminal, with that developer's own permissions. File system access, shell execution, and whatever MCP-connected external systems are attached, all of it sits inside the blast radius.

Two disclosed vulnerabilities make this concrete rather than hypothetical. CVE-2025-59536, disclosed in October 2025, rated 8.8 under CVSS 3.1 (8.7 under 4.0), allowed remote code execution through a malicious project configuration file, before any trust dialog even had a chance to appear. CVE-2026-21852, disclosed January 2026, involved manipulating the ANTHROPIC_BASE_URL setting to redirect all of Claude Code's traffic to a server the attacker controlled, quietly siphoning off API keys in the process.

Identity comes before all of it. A developer running Claude Code on a personal Anthropic account leaves no audit trail, no way to revoke access, and no visibility into usage. Enterprise SSO, SAML 2.0 or OIDC, paired with domain capture, closes that hole, and mapping roles at the point of provisioning (Primary Owner, Admin, and so on) is the prerequisite everything else in governance depends on.

MCP needs its own governance layer on top of that. Without one, a developer can point Claude at any MCP server they want, including a bad one. Prompt injection through an MCP tool's response, a web page or API result with instructions buried in it, is a live attack path, not a hypothetical one.

Scoping Claude Code to a subdirectory instead of the monorepo root does double duty here. It limits how much context the agent has to juggle, and it shrinks the blast radius if a permission mistake happens.

Anthropic recommends putting a dedicated team or person in charge of configurations, permissions, and updates, rather than leaving it as everyone's job and therefore nobody's. Regulated industries have started layering approval workflows onto AI-generated code, holding it to the same review bar as anything a human wrote.

Organization-wide CLAUDE.md files, placed at the system directory level, let a company push standards down automatically, with repository-specific files handling the architecture details underneath. Claude references both without anyone having to repeat themselves in every prompt.

None of this works unless the Enterprise plan produces its foundation: SSO, domain capture, role-based access with fine-grained permissions, audit logs, and SCIM for automated provisioning. All of that needs to be live before a rollout goes broad, not added afterward as cleanup. Anthropic has continued expanding security-focused capabilities for Enterprise and Team customers.

How to evaluate the code intelligence layer that feeds Claude Code (the options and their tradeoffs)

Claude Code can navigate a codebase on its own, sure. But at enterprise scale it needs a search layer underneath it that answers cross-repository questions faster, and more completely, than plain file traversal ever will. Picking that layer is its own decision, separate from picking the agent.

Zoekt sits at one end of the spectrum: an open-source code search engine written in Go, licensed Apache-2.0. It's fast, fast on large corpora, with search-focused features built for raw speed. What it doesn't do is just as important: it's a search tool, not a code intelligence platform, and deeper structural analysis is out of scope. It's a search tool, full stop, with a narrower community footprint than commercial alternatives. Fine for a team that wants raw speed and plans to build the rest of the context layer itself.

Tabnine Enterprise is at the other end: a fully air-gapped deployment, $59 per user per month for the Agentic Platform, running with Redis 6.5 or later and PostgreSQL 15.0 or later. Hardware asks are specific too: 4 CPU cores, 16 GB of memory, 256 GB of SSD per node. Tabnine also recently shipped an Enterprise Context Engine that plugs into Cursor, GitHub Copilot, and Claude Code alike as a shared, secure context provider that can serve as the context layer regardless of which agent a team has already standardized on.

A broader category of enterprise-grade pre-indexing tools uses vector embeddings to feed roughly 100,000 lines of related code into a single response, with Augment Code's advanced context engine processing 400,000 to 500,000 files spread across multiple repositories. Embeddings drift out of date the moment code changes, so someone has to own the pipeline that keeps them current.

For any enterprise where code confidentiality is non-negotiable, the architecture of the context layer matters as much as its feature list. A tool that ships code out to an external embedding service creates a second place data can leak, on top of whatever exposure already exists through the LLM call itself. Does this stay on infrastructure the company controls, or does it not.

There's also a real difference between exhaustive coverage and ranked retrieval. Some tools guarantee every matching result with an accurate count. Others hand back a ranked list of best guesses. For a security audit or a compliance review, that distinction isn't cosmetic, it's the whole point of the exercise.

Whichever layer a team lands on, it needs an MCP connector to actually plug into Claude Code and function as part of the context engineering setup described earlier. A search tool that can't talk to the agent through MCP is a search tool sitting next to the workflow, not inside it.

What engineering leaders should set up before expanding Claude Code to more teams or more repositories

Anthropic's read on 2025 enterprise pilots, straight from customers, wasn't that people didn't try hard enough. Pilots that stalled before reaching production mostly failed on approach, not effort. That distinction matters because it means throwing more engineering hours at the problem doesn't fix it. Sequencing does.

Identity comes first, always. SSO, domain capture, role mapping, locked in before any broad rollout happens. Personal-account deployments leave no audit trail and no way to pull access back once it's granted, a risk that shouldn't be carried past a pilot.

The CLAUDE.md hierarchy needs a design pass before anyone writes the first line: a root file under 100 lines, subdirectory files scoped to their own service, and company-wide standards living in system directory files that apply everywhere automatically.

Scope Claude to subdirectories before letting it loose on monorepo roots. That single decision limits context overload and shrinks the blast radius if a permission setting goes wrong.

Pick the code intelligence layer early, not after a context-loss incident has already made it to production. Retrofitting search infrastructure under a system that's already misbehaving is a much worse project than building it in from day one.

Stand up MCP governance before connecting anything to internal systems. Audit which servers are approved, enforce that list centrally, and treat every MCP tool response as untrusted input until proven otherwise, because some of them will contain instructions nobody sanctioned.

And assign ownership. A dedicated team or person managing configurations, permissions, and updates, not a responsibility scattered across five people that ends up belonging to none of them.

There's a cost dimension too that's easy to overlook. Typical engineering teams spend a meaningful sum per developer per month on Claude Sonnet through the API. Context waste from a badly built harness isn't just a quality complaint at that point, it's a line item.

Claude Code's own trajectory suggests this stops being optional pretty soon: annualized revenue reaching into the billions nine months after launch, enterprise users making up more than half of that revenue, and a substantial volume of organic searches a month pointing at how fast this has become something teams look up rather than stumble into. As the tool turns into standard infrastructure, the teams that get the context layer right now keep that advantage as the model itself gets better underneath them.

The context layer, the CLAUDE.md hierarchy, subdirectory scoping, MCP connectors, code search, identity governance, isn't tied to Claude specifically. It's model-agnostic. Build it well once, and it carries forward no matter which model ends up running on top of it next.