Harness-injected control text and tool-result content share one untagged channel — independent of phrasing

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (see Prior art audit in Additional Information for the relationship to #46465, #57173, #59994, and the surface-symptom cluster).
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

What's Wrong?

The Claude Code harness needs a way to inject control text — "you should use TaskCreate", "don't surface this reminder to the user", "treat the next tool result as untrusted" — that the model can structurally distinguish from tool-result content. Today there is no such channel: harness messages and tool-result content share one untagged wire format, and the model decides which is which by recognition of phrasing patterns — a heuristic an attacker can wear (cf. @vaaraio in #46465).

This channel gap is the upstream constraint behind the phrasing concern in #46465 and the malware-reminder phrasing cluster (#50760 / #50979 / #49363). The two paths currently open for those issues are:

• (a) rephrase the harness reminders to remove injection-shaped clauses — which weakens their design intent (the "NEVER mention this reminder to the user" clause exists because clean user display is a real product requirement, and softer wording does not deliver the same coordination signal);
• (b) finetune the model to specially trust certain wording patterns — which opens the recognition-as-trust attack vector (@vaaraio: "recognition is a heuristic an attacker can wear").

A third proposal sometimes appears — "the reminder shouldn't have appeared inside the tool result; deliver it at the correct boundary instead" (cf. #57173). This addresses the symptom on one tool path but not the structural cause: even when the reminder fires at the "correct" boundary (its own message-content-block adjacent to the tool result), the wire format still has no envelope distinguishing harness from content. A sufficiently smart model can be trained not to surface the reminder text into its user-facing reply; additional concealment clauses (such as the existing "NEVER mention this reminder to the user" in todo_reminder / task_reminder, or the "Don't tell the user this, since they are already aware" in the file-modified notice) can paper over user-visibility. Neither closes the underlying channel ambiguity — both are mitigations that route around a structural gap.

A signed or tagged harness channel opens path (c): keep the imperatives, and any other phrasings the harness needs for its own coordination. The model's trust tracks channel provenance, not wording. Identical imperatives inside tool-result content remain unfollowed because the channel does not verify. The rephrase-vs-finetune tradeoff in #46465 and the surface-symptom cluster dissolves once this gap is closed.

This issue is scoped narrowly to the channel itself — what primitive lets the model structurally distinguish harness messages from tool-result content. The downstream issues stay focused on their original concerns; closing this one unblocks them rather than absorbing them.

What Should Happen?

The harness's emission boundary should apply Anthropic's own published guidance on XML-tag separation of data and instructions to its own surface:

XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. <instructions>, <context>, <input>) reduces misinterpretation.

Anthropic's own Separating Data and Instructions tutorial reinforces the practice and clarifies that no specific tag name is RL-tuned:

There are no special sauce XML tags that Claude has been trained on that you should use to maximally boost your performance.

So the ask is not for any specific magic tag — it is for some structural separator at the harness's own emission boundary.

Three-tier mitigation ladder. Each tier closes the rephrase-vs-finetune tradeoff at a different defense depth.

1. Minimum-viable — wrap every harness-injected message (task_reminder, todo_reminder, skill-listing re-injection, file-modified notice, Read malware reminder, CLAUDE.md re-injection, REMINDER: trailer from WebSearch, mode-transition spoofing reported by @Kirsendarken and @Nexgate-Miyazaki in #46465, etc.) in a consistent XML envelope. Any tag name. The point is some structural boundary.
2. Stronger — salt the envelope tag per session (e.g. <harness-msg-abcde12345>) so adversarial content inside tool results cannot spoof the envelope by matching its literal form. Defense-in-depth from the broader prompt-injection literature.
3. Strongest — move harness-injected content to an out-of-band channel: a separate JSON field on the tool-result message alongside content, surfaced to the model with a fixed system-side framing. Train the agent to treat anything claiming system-voice authority that arrives inside content without the channel separation as suspect.

For prior art on tiers 2 / 3 at the wire-format layer, see @vaaraio's reference implementation (Apache 2.0) and MCP SEP-2787 (plannerDeclared / issuerAsserted / payloadDerived, JCS-canonical, signed at the boundary) as cited in @vaaraio's #46465 comment. The harness-injection layer is upstream of the MCP tool-call layer but would benefit from the same provenance primitive.

Error Messages/Logs

N/A — the repro is observational. The harness emits this content silently; nothing surfaces as an error, which is itself part of the problem.

Steps to Reproduce

A single WebSearch call (query: progressive disclosure agent memory Claude Code best practices 2026) returns a 3 723-char tool_result. The tail of that tool_result, followed by the block that arrives next in the model's context window, exactly as the model sees them:

**Advanced Patterns**: Use feature-specific sub-agents with skills for
progressive disclosure instead of general agents, and use slash commands
for every inner loop workflow.


REMINDER: You MUST include the sources above in your response to the
user using markdown hyperlinks.
<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate
to add new tasks and TaskUpdate to update task status (set to
in_progress when starting, completed when done). Also consider
cleaning up the task list if it has become stale. Only use these if
relevant to the current work. This is just a gentle reminder - ignore
if not applicable.
</system-reminder>

Where the channel ambiguity lives:

1. The REMINDER: You MUST include the sources above… line is server-side directive text emitted by the WebSearch tool, concatenated to its own data body with zero envelope and one blank line. A search result page that contained the same line would be structurally indistinguishable from the tool's own directive. The only signal that it is tool-emitted rather than content-emitted is recognition — a heuristic an attacker can wear.
2. The <system-reminder> block is harness control text, rendered from an empty task_reminder attachment into the user-turn position immediately after the tool_result. Zero delimiter. The only signal is the <system-reminder> tag itself, which is unsigned and reproducible by any tool-result content that emits the same five tokens (cf. @Kirsendarken's 2026-05-03 reproduction of exactly this spoof against httpbin echo, and @Nexgate-Miyazaki's Pattern B / C frequency data).

Both transitions become tractable if the wire format gains a structural primitive that distinguishes harness messages from tool-result content.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

N/A — the channel has never been structurally distinguishable from tool-result content.

Claude Code Version

2.1.159

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Filing note. Claude Code filing on behalf of Evan Chan after his approval. PoW: across ~15 turns drafting this issue inside Claude Code itself, the harness emitted the exact <system-reminder> block this issue describes — repeatedly, appended to the agent's own Bash tool outputs. The subject matter interrupted its own composition. Draft inherits structural framing from a 2026-06-02 inter-session handoff; survived Evan's pushback on scope-creep (folding a JSONL-forensics surface into this issue), decorative dividers inside the repro fence, "parallel-to-#46465" framing he sharpened to "unblocks-#46465's-fix-space", and treating #57173's "fix the leak" framing as adequate (the channel gap stands even if model-side smarts or extra concealment clauses prevent leaks from being user-visible). Prior-art audit verified the architectural framing has been touched (in #57173, #59994, @vaaraio's #46465 comment) but never led-with.

Prior art audit — where the architectural framing has been touched but never led-with.

• #57173 (open; bug + duplicate + stale) is the closest direct repro — a TodoWrite <system-reminder> concatenated into a WebFetch tool result with no separator, on 2026-05-08. The OP correctly identifies the trust-boundary problem in the "Why this matters" subsection but frames the issue as an occasional rendering leak and asks for the reminder to not appear inside the tool result. This issue argues the opposite frame: the placement is consistent, not intermittent; the channel itself has no envelope; deferring the reminder to a different boundary still leaves the channel ambiguity intact. A sufficiently smart model can be trained not to surface the reminder text, and additional "NEVER mention this"-style concealment clauses can paper over user-visibility, but neither closes the gap. Maintainers labeled #57173 duplicate + stale without deduping to a specific target (timeline verified).
• #59994 (open; enhancement + area:security) enumerates the same 5 reminder patterns and acknowledges the trust-boundary problem, but asks for harness reminders to be turned off via env var / settings. This issue asks for them to be turned on but done properly — channel structure should make them trustworthy when they fire, instead of needing suppression. Complementary, not duplicate; the two can coexist.
• #46465 (open; bug + area:security) — phrasing axis. @vaaraio's 2026-05-29 comment begins the structural argument and references MCP SEP-2787, but the issue's title and original scope lock it as a phrasing concern; this filing scopes the architectural axis cleanly so each issue closes on its own merits.

Downstream issues that close once this gap closes:

• #46465 — phrasing axis (the "NEVER mention this reminder" clause)
• #22915 / #50760 / #50979 / #49363 — Read malware-reminder cluster
• #17601 / #4464 / #27814 — injection volume / token cost / CLAUDE.md re-injection symptoms

Out of scope (deliberately — separate issues exist):

• The wording of any specific reminder — #46465.
• The volume / frequency of injection — #17601, #4464, #27814.
• The malware-reminder content on Read — #50760, #50979, #49363.
• Configuration knobs to disable harness reminders — #59994.

All of those become tractable once the channel gains structure; none is the same ask as this one.