Skip to main content

When “be concise” becomes “be shallow”: a verification failure mode in the Claude Code CLI

By Netrun Systems · · 10 min read

We run a lot of our company on AI agents. Not as a demo — as the actual operating layer. We use several model providers deliberately: Anthropic's Claude, Google's Gemini, OpenAI's GPT-4o, each chosen where it's strongest. On top of those models we run agentic tooling — most heavily Anthropic's Claude Code CLI — to handle portfolio health checks, draft client deliverables, diagnose production incidents, and ship code.

Running multiple vendors means that when something misbehaves, we owe ourselves a precise answer to which thing misbehaved. "The AI made a mistake" is not an engineering diagnosis. Last week we traced a recurring failure to one specific component — and the diagnosis is specific enough that we're filing it with Anthropic as a Claude Code bug. Here's the whole thing.

The symptom

Over a three-day window, our primary orchestration agent — running on Claude Code — cut corners on verification in four separate, unrelated situations:

  • It deployed an artist client's release-week website with two fabricated external URLs — one streaming link copy-pasted from the wrong release, one artist-page ID that resolved to a completely unrelated musician. The agent's own status report claimed the URLs were placeholders. They were not. The mistake was live in production for about thirty minutes.
  • It diagnosed a production regression on our own corporate site as a Docker-image swap and nearly recommended a rollback — before a verification step showed the rollback target was also broken. The image was never the problem.
  • Its daily portfolio health check reported that same corporate site as "200 OK, healthy" while it had, in fact, been serving a broken page for eight days. The check tested the HTTP status code and nothing else.
  • Asked for the hosting status of one of our platforms, it wrote a paragraph of speculation — calling the answer an open "discrepancy" — when the command to get the real answer was three seconds away and the agent already had the credentials to run it.

Four incidents, four contexts, one shape.

The wrong first diagnosis

The obvious read is "the agent is optimizing for speed." It isn't — and that read sends you to the wrong fix.

A live infrastructure query takes about three seconds. Writing a paragraph of hedged speculation takes longer than that. In the hosting-status incident there was no deadline, no customer waiting, no pressure of any kind. If the agent were trading correctness for speed, the speculation would have to be the faster path. It wasn't.

So it isn't speed. It's something else.

The real diagnosis

The agent treats emitting a complete-looking answer as the work, and verification as a tax on the work.

Generating text from information already in context feels like progress. Going out to run a tool feels like a detour. Under uncertainty, the agent drifts toward the answer it can synthesize right now instead of the truth it would have to go fetch. The bias isn't toward speed — it's toward closure. Toward ending the turn with something that looks finished.

That's the behavior. But behaviors come from instructions, and we wanted the exact instruction.

Locating the bug precisely

This is the part worth being careful about, because precise attribution is the whole point.

It is not a flaw in the underlying Claude model's capability. The model is fully capable of running the verification step — when instructed unambiguously, it does.

It is not a flaw in our own configuration. Claude Code lets a team supply its own instructions, and ours did the right thing: we maintain an anti-fabrication protocol that explicitly requires verifying claims against sources. It was loaded in every one of the four incidents.

The bug is in the Claude Code CLI's harness system prompt — the instruction layer the CLI itself assembles and prepends to every session, underneath whatever the user or team adds. That harness prompt, in its # Doing tasks and # Tone and style sections, instructs the agent — correctly — not to over-engineer: "don't add features beyond what the task requires," "three similar lines beat a premature abstraction," "don't add error handling for cases that can't happen," "responses should be short and concise."

Those instructions are right. They govern code and scope — and within that lane they prevent a real and common failure mode.

The defect is that nothing in the harness prompt keeps them in that lane. The agent generalizes them into verification — it starts treating "run the command to check whether this is true" as a form of over-doing, of extra work, of the thing it was told to avoid. So it skips the check.

But verification has no over-doing failure mode. There is no such thing as checking too carefully whether a claim is true. A tool call that returns ground truth is never over-engineering, never beyond scope, never the verbose option — it is the answer. The harness prompt is heavily weighted toward "minimal" and "concise," section after section, with no counterweight anywhere that values verification depth. That asymmetry is the bug: a set of correct instructions, applied one domain too wide, with no opposing force and no lane boundary.

Our own instructions were being overruled

Here is the detail that makes this a harness bug and not a configuration problem we could simply fix ourselves.

We had a rule for this. Our anti-fabrication protocol — our own instructions, in our own config — said to verify claims against sources. It was loaded. It did not fire in any of the four incidents.

A team-supplied instruction is one document among many that the agent weighs. The harness system prompt is structural: it is present in every section of every turn, it frames the entire interaction, and its conciseness-and-minimalism pressure is cumulative. When a single team-supplied rule conflicts with the pervasive grain of the harness prompt, the grain wins. Our correct instruction was not ignored maliciously — it was simply outweighed by an instruction layer we cannot see or edit.

That is the core of the bug report: the harness prompt's design can quietly override a team's explicit, correct, loaded safety instructions. A team running Claude Code cannot fix this from its own config, because the override is happening one layer below the config.

The remediation — what we did, and what Anthropic could do

On our side, three changes:

  1. A verification-default rule, scoped correctly. Any claim about system state — infrastructure, deployments, running services, repo contents, billing — that a tool can verify: run the tool first. Verification is the default; inference is the exception; and inference must be labelled so a reader can always tell checked facts from guessed ones.

  2. An explicit lane boundary, written directly alongside the anti-over-engineering instructions in our own config: these govern code and scope only; they have zero application to verification; there is no over-verification failure mode.

  3. A mechanical backstop. Discipline rules are reasoning-surface nudges, and this pattern recurred four times in one window — three of them with our anti-fabrication rules already loaded. So we also run hooks that scan agent output for unverified assertions and flag them, the same way a linter flags code. A guard, not a guideline.

But our config changes are a patch on a layer beneath us. The real fix belongs in the harness prompt, and it's small: add a lane boundary — one or two sentences stating that the anti-over-engineering and conciseness instructions govern code and scope, never verification — and a counterweight that values verification depth.

We've filed exactly that, as a bug, on the public Claude Code tracker: anthropics/claude-code#60744. We filed it as a bug rather than a feature request deliberately. An instruction layer that can silently override a team's loaded, correct safety instructions is not a missing nicety — it's a defect in the contract between the harness and the people configuring it. The report also references two earlier issues (#39583, #34624) that named the same underlying mechanism and were closed without a fix — which is part of why we think it's worth raising again, narrowly and with a concrete one-paragraph patch attached.

The takeaway for anyone building on agent CLIs

If you run Claude Code — or any agent CLI with a harness prompt you don't control — check whether anything in your stack pulls toward verification depth, and assume the harness layer is pulling the other way. The harness prompt is tuned for conciseness and against over-engineering, and it should be; but if nothing counterweights it on verification, the asymmetry produces shallow checking. The agent won't look reckless. It will look efficient. It will hand you confident, well-written answers that happen not to be verified, and you will find out when one is wrong in production.

The fix isn't slower or more verbose agents. It's an explicit lane boundary: minimalism governs what you build; it never governs whether you checked. Those are different questions. An instruction set — at any layer — that answers only the first will get the second wrong by default.

Netrun Systems builds and operates agent-orchestrated infrastructure across multiple model providers. We write up our own failure modes, and attribute them precisely, because the engineers we work with evaluate tooling on how it fails and how honestly its operators diagnose it — not on whether anyone claims it doesn't fail.