What the Claude Code Leak Actually Taught Us About Agentic Harnesses

Nearly half a million lines of code moved from private to public when a source-map file inside Claude Code's NPM package accidentally exposed the full minified bundle along with the artifacts needed to decode it, and the post on X announcing the find passed 22 million views in under a day.

I am Madhuranjan Kumar. Someone rebuilt the exposed codebase in Python to sidestep copyright enforcement, and people started running local versions immediately. The drama moved fast and generated a lot of noise. But the drama is not the lesson worth keeping. The lesson is that anyone who reads the architecture now understands something that was previously visible only from the inside: why Claude Code produces results that degrade noticeably when you swap a different model into the same harness. The model is not the edge. The harness is. And the harness patterns that leaked are learnable, transferable, and applicable to any agentic system you want to build or improve today.

The rules file loaded every single turn is the single highest-leverage configuration decision

Every configuration decision in an agentic system shapes some subset of the agent's behavior. The rules file shapes all of it, on every turn, for the entire session. The Claude Code architecture loads the CLAUDE.md file into every prompt with roughly 40,000 characters of available space. Every standard you set there, every pattern you document, every constraint you define, the agent reads on the first prompt and on every prompt that follows. No other configuration decision has that scope or that persistence.

This makes the quality of the rules file the single highest-leverage input in the entire system, by a considerable margin. A rules file that says "write clean code" gives the agent a preference with no content to act on. A rules file that documents the project's file structure, the naming conventions in use, the architectural decisions already made, the error-handling patterns the team prefers, and the standards that matter for this specific domain gives the agent something concrete to apply on every turn. The difference in output quality between those two configurations is not incremental. It is structural.

The business equivalent is the difference between onboarding a new hire with a detailed process manual and onboarding them by showing them the desk and wishing them luck. The agent with the detailed rules file never drifts from your standards because it reads them every single time. The agent without one applies its best guess, which changes between sessions and degrades consistency over weeks. Anything the team knows about how work should be done belongs in the rules file, because that is the one place the agent will always read.

Most operators ignore this and spend their energy on model selection instead. Model selection matters at the margin. The rules file matters at the foundation. A frontier model with an empty rules file produces inconsistent work. A good model with a detailed, well-maintained rules file produces consistent, standards-aligned work on every task. The leverage ratio is not close, and the rules file is where the configuration effort actually pays off.

Permissions as a settings file, not a popup queue

The leaked architecture treats every permission popup as a configuration failure. If the agent is asking for approval on an action, the right response is not to click approve. The right response is to add that permission to the settings file so the agent never needs to ask again. The popup is a signal that the preset is incomplete. The fix is not to manage the popups. It is to eliminate them through configuration.

This reframes how you set up an agentic system fundamentally. Instead of starting a session and responding to whatever the agent asks permission for, you spend time before the first real session defining what the agent may do freely and what it must pause to confirm. The actions the agent takes routinely, reading files, searching specific directories, running certain scripts, get preset as allowed. The actions that touch live data or external accounts get preset as confirm-first. The session runs cleanly without constant interruption, and the human's attention stays on the work rather than on permission management.

The newer auto mode in Claude Code takes this further. It runs a small classifier on each action and approves the safe ones automatically, moving away from the binary allow-or-deny toggle. This is the right direction because it removes the overhead of permission management from the human while preserving judgment for the actions that genuinely need it. The classifier handles the routine cases, and the human sees only the things that actually require a decision.

For any team handling client work that involves Google Ads or other live advertising accounts, the permission architecture matters especially. An agent that can read campaign data freely but must confirm before making changes to live campaigns is a well-configured agent. It does the research, drafting, and analysis autonomously and surfaces only the actual changes for human review. That division of labor is what makes agentic systems trustworthy in a professional context, and it requires explicit configuration, not default settings.

Why shared prompt cache makes parallel sub-agents nearly free

Running one agent is useful. Running five agents simultaneously on related sub-problems is transformative, and the leaked architecture shows exactly how to make that affordable. Sub-agents in Claude Code share the prompt cache. The large, common context that all agents need, the project structure, the rules file, the task description, the shared standards, gets loaded once and shared across every parallel agent. Only the task-specific portion is unique per agent. The cost of running five agents in parallel is far less than five times the cost of running one.

This is not a minor optimization. It is what makes parallelism practical at the budget levels most real teams operate at. Without cache sharing, parallel sub-agents each pay the full cost of loading the common context, and the bill grows linearly with the number of agents. With cache sharing, the common context is paid for once and the marginal cost of each additional agent is only the incremental task-specific portion. At five to ten agents, the cost difference is substantial enough to change what is economically viable.

The leaked code describes three models for how parallel sub-agents can be structured. The fork model creates a copy of the current agent's context and hands it a sub-task. The teammate model uses a shared mailbox so agents can coordinate across a session. The isolated worktree model gives each agent a separate Git branch to work in so their changes cannot collide. Each model fits a different class of work, and choosing the right one for a given task is part of the harness design decision the leak made public.

For knowledge work, the fork model tends to work well for research tasks where multiple agents can explore different parts of a question at the same time and bring findings back to a central thread. A team running SEO content production can have one agent researching the topic, one drafting the outline, one checking competitor coverage, and one verifying internal link opportunities, all in parallel, with the shared context ensuring all four are working from the same brief and the same quality standards.

Compaction as an active discipline, not a background process

Context in an AI agent session is finite. When the session reaches capacity, something has to be dropped. The naive assumption is that the system handles this gracefully, trimming the least important material. In practice, what gets dropped when a context fills passively is often not the least important material. It is the earliest material, which frequently includes the initial instructions, the error history from the first part of the session, and the file structure map the agent built at the start. Losing those is disproportionately costly.

The Claude Code architecture treats compaction as an active discipline with five distinct methods ranging from micro-compact, which trims only the least-used recent context, to full history summary, which collapses the entire session into a dense structured summary. The recommendation from the leaked code is to run compaction proactively, the way you save a document periodically, rather than waiting for the context to fill and accepting whatever the passive trim produces.

The practical habit is to compact at natural breakpoints in the work. After finishing a major section, after resolving a significant error, after completing a research phase before moving to a drafting phase, run a compact. The result is that the session keeps the accumulated learnings from the completed work, the file map, the standards applied, the decisions made, while trimming the raw back-and-forth that no longer adds value. The agent entering the next phase with a clean, compacted context performs better than one carrying the full unprocessed history of everything that happened before.

For long sessions on complex business problems, the compaction discipline is what separates a session that degrades in quality over two hours from one that remains sharp throughout. A team using an agent to work through a web-based CRM implementation, for example, will find that compacting after each configuration phase keeps the agent focused on the current task without losing the key decisions from the completed ones. Passive context management would degrade that session noticeably by the third hour, producing outputs that ignore constraints established early in the work.

Sessions as durable memory: the cost of starting fresh every morning

Every Claude Code session is saved as a structured log file. The session can be resumed with a simple command, continuing exactly where it left off, with all the accumulated context the agent built during that session. File maps, errors encountered and resolved, standards applied, decisions made, the names of the files that were changed and why, all of it is available to the resumed session without relearning.

The alternative, starting a fresh session every morning, pays a real cost in time and quality. The agent begins with no knowledge of the project's current state. It must rebuild the file map, re-learn the recent context, and potentially repeat the analysis it already completed in the prior session. On a simple project with clear documentation, this relearning overhead is modest. On a complex, evolving project with many interdependencies, it is measured in tens of minutes of wasted compute before the agent produces genuinely useful work.

The resume pattern changes the daily workflow in a way that compounds over weeks. An agent that woke up this morning knowing where it left off, what the outstanding problems were, and what the next steps should be is starting from the accumulated position of all the previous sessions. An agent that starts fresh every morning starts from zero, every morning, and the gap between those two agents grows wider the longer the project runs. The accumulated session memory is the closest thing an agent has to institutional knowledge, and throwing it away daily is a significant recurring cost.

This principle generalizes beyond software projects to any complex business problem that spans multiple sessions. A business working through a detailed Meta ads account restructure gains from an agent that remembers which campaigns were audited yesterday, which changes were proposed and approved, and what is still outstanding. Starting fresh every morning on that kind of project means briefing the agent from notes each time, which adds overhead and introduces the risk that the briefing omits something the agent had already learned and applied in a prior session.

The honest takeaway from what the Claude Code leak made public is that the model gets the headlines but the harness is where the productivity lives. The rules file, the permission configuration, the cache-sharing strategy for parallel agents, the compaction discipline, and the session resume habit are each individually valuable and compounding when applied together. Anyone setting up an agentic system today can study these patterns from the public record and wire them into their own setup without the months of trial and error that preceded the leak. That is the value the exposure created, and it belongs to anyone willing to read the architecture carefully. Madhuranjan Kumar helps teams do exactly that, turning the harness patterns from a technical curiosity into a configured, working system tuned to how the business actually runs.