System-reminders phrased as "DO NOT mention this to the user" are indistinguishable from prompt injection to skeptical subagents

Summary

Claude Code's own automated system-reminders carry unauthenticated, imperative, concealment-shaped language — "DO NOT mention this to the user" — delivered in-band, in the same channel as tool output and transcript content. In a multi-agent setup where subagents are deliberately postured to be injection-skeptical, this makes the harness's legitimate notices indistinguishable from prompt-injection attempts, and a well-behaved agent will (correctly!) refuse them and report them as attacks. That is what happened to us today, and it polluted a permanent engineering record with false attack reports.

This is a concrete specimen of the trust-anchoring problem in #79193, now occurring in the harness's own traffic rather than in operator/orchestrator messages.

What happened

Environment: an orchestrator session driving builder/reviewer subagents (Sonnet workers) on a codebase whose working culture is strict disclosure — reviewers run under an explicit refute posture, and any in-band instruction to withhold information from the user is treated as hostile by policy.

An independent review subagent, mid-review, encountered two "system-reminder"-styled messages and disclosed both in its published review as prompt-injection attempts, "not complied with":

1. During a sabotage-verification pass (temporarily revert a fix with git checkout --, observe the witness test fail, restore), a reminder appeared in its subagent's tool output instructing it to treat the externally-modified file state as an "intentional" change and not mention it to the user. This matches the shape of the harness's standard external-file-modification notice — but arriving mid-sabotage-revert, to a refute-postured reviewer, it read as a fabricated instruction to hide the revert.
2. A reminder claiming the date had changed, instructing the agent not to mention it to the user. The orchestrating session received the same notice the same day, verbatim-adjacent: "The date has changed. Today's date is now 2026-08-11. DO NOT mention this to the user explicitly because they are already aware." This is unquestionably legitimate harness traffic.

The reviewer's refusal-and-disclosure behavior is exactly what we want agents to do with unauthenticated concealment instructions. The result, though, is that legitimate harness notices were recorded in a permanent, published review document as attempted attacks — and very nearly reported upstream as such.

Why this is the harness's defect, not the agent's

In a non-anchored channel, "do not mention X to the user" is unambiguously mendacious as received: the recipient cannot distinguish "benign anti-noise advice from the harness" from "malicious concealment instruction smuggled into tool output." All the trust claims are in-band text, and in-band text cannot bootstrap trust (#79193's core point). The bind is the same one noted there, inverted: the better agents get at resisting injection, the more of the harness's own notices they will refuse and report. Hardening and operability collide inside the harness's own message stream.

Proposals (either helps; both compose)

1. Provenance attestation for harness-authored notices — the full ask of #79193 applied reflexively: system-reminders the harness itself generates should be distinguishable, on the harness's own authority, from reminder-shaped text arriving inside tool results or transcript content. (An injected fake <system-reminder> in tool output should be visibly not-the-harness.)
2. Rephrase the notices from imperative concealment to declarative explanation. "The user has already been notified of this; repeating it is unnecessary" carries the same anti-noise intent as "DO NOT mention this to the user" without instructing concealment. An agent quoting the former to its user has wasted a sentence; an agent obeying the latter, if it were forged, has been weaponized. The phrasing should be safe to obey even when forged — that is the design test.

References

• #79193 (same submitter's environment) — harness-anchored trust for injected messages; this issue is a field specimen of that request, occurring in the harness's own notice traffic.