Claude Code's silent context: why the same prompt drifts between runs

Anthropic published documentation on July 24, 2026 admitting something governance teams need to read carefully: the prompt an engineer writes is only a small part of what Claude Code actually receives. The rest , skills, CLAUDE.md files, memory, hooks, MCP server outputs , is assembled silently by the harness. That assembly differs between environments. Which means two runs of the same prompt, on different machines, are not equivalent executions.

What Anthropic's docs actually say#

The July 24 post from Anthropic describes removing over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5, with no measurable loss on coding evaluations. The capacity for constraint didn't disappear , it moved. Fixed rules in the system prompt were replaced by dynamically loaded context: skills that load when needed, auto-memory that saves and replays preferences across sessions, MCP tools with deferred definitions that the agent fetches at runtime via ToolSearch.

The post names the sources explicitly: system prompt, skills, CLAUDE.md files, memory, and other sources. "Other sources" includes hooks and connected MCP servers. None of these are visible in the prompt text. All of them influence the output.

This is not a theoretical concern. The Claude Code Playbook's debugging chapter exists precisely because the loaded configuration is non-obvious , its loading line states that when Claude ignores instructions, the cause is almost always that a file didn't load, loaded from a different location, or was overridden by precedence. That's a configuration drift problem embedded in the normal operation of the tool.

The harness state is the effective input#

The standard mental model for AI coding agents treats the model as the variable and the prompt as the input. Both are stable. The output should therefore be deterministic given the same model version and prompt.

That model is wrong for Claude Code in its current form.

The DataSci Ocean writeup on Claude Code's architecture frames it correctly: Claude Code is a concrete instance of the "Model + Harness + Context" framework. The model is frozen. The harness and the dynamically assembled context are not. A CI runner that has no user-level memory, no locally installed MCP servers, and a minimal .claude directory is running a materially different agent than a developer's laptop with six months of auto-saved memory, a custom skills tree, and three connected MCP servers.

The headless mode documentation confirms the asymmetry. In headless operation, "there is no one to approve prompts, so permissions must be configured up front." That configuration is the harness state. The same prompt sent through --print in CI and through an interactive session on a laptop will receive different context, potentially different tools, and potentially different permissions , depending entirely on what the harness loaded before the prompt arrived.

Why this is a supply-chain question#

Reproducibility is the foundation of supply-chain trust. A build that produces different artifacts from the same source code and the same inputs is not a trusted build. The same applies to agent-generated code.

If a Claude Code run in CI generates a PR, the artifact of that run is the diff. The inputs include the prompt, the model version, and the harness state. Teams that version-control their prompts and pin their model versions are governing two of three inputs. The harness state , which hooks fired, which skills loaded, which MCP servers connected, which memories were active , is typically ungoverned and unlogged.

That gap is where drift lives. A security-relevant skill that exists on an engineer's laptop but not in the CI container will produce different behavior from the same prompt. An auto-memory entry that instructs Claude to skip certain file types on one machine has no effect on another. The PR looks like the same agent ran it. It wasn't.

Claude Code v2.1.219, released July 24, added mcp_server_errors to the headless stream-json init event , listing MCP config entries skipped by validation , which signals that Anthropic is aware CI runs need visibility into what context actually loaded. That's a diagnostic signal, not a governance control. The field tells you what was skipped. It doesn't tell you what the run would have looked like if those servers had connected.

What the harness audit looks like in practice#

The diagnostic commands documented in the Claude Code Playbook give a starting point. Running /context shows the current session's context window by category: system prompt, memory, skills, MCP tools, messages. Running /hooks shows active hook configuration. Running /mcp shows connected servers and their status.

In a governed CI environment, these outputs should be captured at session start, logged as artifacts alongside the PR, and diffed across runs. A PR generated by Claude Code becomes reproducible only if the harness state that produced it is recorded. Without that record, a reviewer looking at the diff has no way to know whether the agent that generated it operated under the same constraints as any previous run.

The /doctor command (added in v2.1.205) performs a setup checkup that diagnoses malformed settings files, unused extensions, and trimming issues. Running it as a CI preflight step and failing the pipeline on unexpected output is a concrete control. Anthropic explicitly recommends it in the July 24 post for rightsizing skills and CLAUDE.md files.

The governance surface has shifted#

Most teams governing Claude Code runs are checking the prompt and the diff. The Anthropic documentation from July 24 makes clear that neither is sufficient. The effective input to the agent is the harness state plus the prompt. Both need to be in scope for review.

This is the same architectural pattern visible in other agent failure modes , the failure surface is not the model, it is everything the model receives before it starts generating. Auditing a PR requires auditing the context that produced it, as described in how Hyrax reviews code. The diff is the output. The harness state is the input. Governing one without the other is incomplete.

Practically: version-control the .claude directory. Pin MCP server configurations. Capture /context output as a CI artifact. Treat the mcp_server_errors field in stream-json as a failure signal, not a warning. And run claude doctor before the agent run, not after the PR is already open.

Hyrax is live at hyrax.dev.