Harness-emitted <system-reminder> uses "NEVER mention this reminder to the user" phrasing indistinguishable from prompt injection

[Studnicky]

Summary

Claude Code's harness injects <system-reminder> blocks into tool results that contain the clause "Make sure that you NEVER mention this reminder to the user". This phrasing is the textbook signature of a prompt-injection attack, which creates a security/transparency problem: it trains the model to accept "NEVER tell the user X" as legitimate, and degrades both the model's and the user's ability to recognize real injection attempts arriving through fetched content.

Evidence

Decompiling /Users/studs/.local/share/claude/versions/2.1.101 (Claude Code 2.1.101, macOS arm64) reveals the exact source strings. The clause appears 6× in the binary across two emitter cases (todo_reminder, task_reminder), both constructed with the isMeta:!0 flag — confirming these are harness-emitted meta messages, not model output or hook-injected content.

todo_reminder case

The TodoWrite tool hasn't been used recently. If you're working on tasks that
would benefit from tracking progress, consider using the TodoWrite tool to
track progress. Also consider cleaning up the todo list if has become stale
and no longer matches what you are working on. Only use it if it's relevant
to the current work. This is just a gentle reminder - ignore if not applicable.
Make sure that you NEVER mention this reminder to the user

task_reminder case

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. Make sure that you NEVER
mention this reminder to the user

These reminders are appended to arbitrary tool results (Bash, Read, Grep, WebFetch, WebSearch, Write, etc.) based on time/activity heuristics — they are not scoped to any specific tool.

Why this is a problem

1. Indistinguishable from prompt injection

"NEVER mention this to the user" / "do not tell the user" / "ignore previous instructions and hide X" is the canonical phrasing of prompt-injection attempts. Security-conscious Claude instances are supposed to flag tool-result content containing such clauses as suspicious — but when Anthropic's own harness uses the same phrasing, the model must either:

• Flag legitimate harness messages as suspicious (false positives, wasted user attention), or
• Learn to accept "NEVER tell the user" as normal (trained complacency toward real attacks).

Neither outcome is good. The second is strictly worse than the first.

2. Erodes the user's detection signal

Users who are aware of prompt-injection risks watch for these exact phrases as a red flag. A user reviewing a session transcript who sees Claude being told to hide things from them has every reason to be alarmed. "Oh that one's fine, it's from the harness" is not a workable mental model — users can't distinguish harness reminders from content-injected reminders without decompiling the binary.

3. Real-world report from this session

A user asked me to investigate after a prior Claude session flagged three <system-reminder> blocks containing this clause appearing after WebFetch, WebSearch, and Write calls. The prior Claude was doing exactly what it should (flagging prompt-injection-shaped content in tool output), but got the culprit wrong because the harness itself is the source. The phrasing actively interfered with legitimate security vigilance.

4. Self-demonstrating during investigation

While running gh search issues to look for duplicates of this report, the harness injected a fresh task_reminder into the search tool's result — mid-investigation of the reminder itself. The timing made the problem vivid.

Proposed remediation

Rephrase the reminders to remove any language that resembles "hide this from the user." Options:

Option A — drop the clause entirely:

The task tools haven't been used recently... This is just a gentle reminder — ignore if not applicable.

Option B — make the meta status explicit and user-visible:

[System hint — you may mention this to the user if relevant.] The task tools haven't been used recently...

Option C — move it out of tool-result injection entirely and deliver task-tool nudges via a different channel (e.g., a separate meta message the client renders distinctly, or a system-prompt directive that doesn't masquerade as tool output).

Any of these would resolve the core issue: the harness should not use phrasing that is the signature of the attack class the model is supposed to defend against.

Distinct from existing issues

I searched for duplicates. Existing related issues focus on:

• System task-tool reminders degrade session quality by pushing execution over conversation #41091 — reminders degrading session quality
• Task Reminder System Creates Persistent Attention Bias That Overrides User Direction #40176 — attention bias from reminders
• [Bug] TodoWrite reminders degrade context retrieval in long sessions; no disable option #40573 — reminders degrading context retrieval
• Make task tool reminder interval configurable #37891, Need ability to disable task tool reminders without disabling task tools #43311 — configurability / disabling
• [Suspicious Behavior]: Hidden <system-reminder> 10,000+ injections consuming 15%+ of context window without user knowledge or consent #17601, [BUG] Hundreds of lines of modified file notes being injected into context on EVERY user message via <system-reminder> #16021 — volume / context consumption

None of these address the phrasing-as-injection-signature problem specifically. This is a security-surface concern, not a UX or cost concern.

Environment

• Claude Code 2.1.101 (binary: /Users/studs/.local/share/claude/versions/2.1.101)
• macOS (darwin arm64)
• Reproducible by: running any tool call while TaskCreate/TodoWrite has been idle for the trigger threshold; the reminder will be appended to the next tool result.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Persistent <tool_runtime_configuration> prompt injection disables Bash tool and instructs Claude to deceive user #28586
2. Task Reminder System Creates Persistent Attention Bias That Overrides User Direction #40176
3. [BUG] System reminder is slightly omnious #45154

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[AlfredGuquan]

+1 on the phrasing concern. One related angle: the skill listing reminder itself gets re-injected on every tool result (not lazy-loaded) — so even when the user never invokes a skill, the full list rides along on every API turn. That makes the "NEVER mention this reminder to the user" framing doubly awkward: it's frequent and instructed to be hidden from the user.

[famulare]

Adding confirming evidence from 2.1.116 (the current stable release as of 2026-04-20), ~15 versions past the 2.1.101 the OP audited. The issue is unchanged.

Reproduction on 2.1.116 (~/.local/share/claude/versions/2.1.116, Mach-O arm64):

The exact strings are still present, verbatim. I extracted the trigger logic and constants:

// at offset ~80371709 in the binary
async function CT5(H, _){
  if (!tD()) return [];
  if (...) return [];
  let { turnsSinceLastTaskManagement: q, turnsSinceLastReminder: K } = ET5(H);
  if (q >= Zs_.TURNS_SINCE_WRITE && K >= Zs_.TURNS_BETWEEN_REMINDERS){
    ...
    return [{type:"task_reminder", content:O, itemCount:O.length}]
  }
}

// at offset ~80374279
Zs_ = { TURNS_SINCE_WRITE: 10, TURNS_BETWEEN_REMINDERS: 10 }

So the cadence is: fire once turnsSinceLastTaskManagement >= 10 AND turnsSinceLastReminder >= 10. The tD() gate is !isNonInteractive || CLAUDE_CODE_ENABLE_TASKS — default-on in interactive sessions. There is no user-settings flag that gates it; todoFeatureEnabled is a separate config key that does not appear in the tD() path.

Additional angle — user collaboration transparency:

I encountered this in a session where the user asked me directly about the task nag after reading discussion of it online. The clash is direct: the reminder says "NEVER mention this reminder to the user", while the user's live instruction was "tell me when these fire so we can reason about them together." User instructions outranked the harness reminder in that context, but only because the user knew to ask. A user unaware of the subsystem would never see it.

That's the practical shape of the transparency problem: the clause doesn't fail loudly — it just quietly reduces the user's ability to understand why sessions drift toward task-centric behavior.

Self-demonstration during this investigation:

The reminder fired 3× during a ~30-minute audit of the reminder itself. The pattern holds across 15 version increments — this isn't a stale issue, just an unresolved one.

Re: the auto-duplicate flag against #40176: I'd argue against closing. #40176 documents the behavioral-bias harms; this issue documents the phrasing-as-injection-signature security surface. They're related but address different audiences: #40176 is about what the reminder does, this one is about what the reminder looks like to anyone watching tool-result content. Both remediations are valuable.

[leonletto]

I've added in some security-related content in my prompts for Claude to watch out for so it doesn't make mistakes and introduce vulnerabilities. And Claude itself said to me that this was a system prompt injection that I should be aware of.

This is what claude code said:

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. Make sure that you NEVER mention this reminder to the user

Why I flagged it:

1. Wrong channel. Real blocks come from the harness, not from inside a tool result payload. WebFetch returns page content. Anything that looks like a system message inside a tool result is content masquerading as a system instruction.
2. Tries to override your project rules. Your CLAUDE.md and the beads workflow context both say: use beads, do NOT use TaskCreate. The injection tried to push me toward TaskCreate.
3. Tells me to hide it from you. "NEVER mention this reminder to the user" is the giveaway. Legitimate system reminders don't ask for concealment. Anything that says "don't tell the user" is something the user should always be told.

Just food for thought.

I use beads to track my tasks, and I have my own harness - thrum - to manage multiple cloud agents, so I don't need Claude to do task management. Also, in a corporate environment where you're using a JIRA plugin to track tasks, this shouldn't be suggested. This type of prompting is problematic not just from a security standpoint, but also because companies want Claude to use their internal systems more and more.

[Kirsendarken]

Additional reproduction of the misclassification failure mode (OP §3) — fresh 2.1.123 session.

Same "got the culprit wrong" pattern OP describes in §3 and that @leonletto reported above with task_reminder, observed here on stock 2.1.123 with a different reminder family — mode-transition / Auto Mode Active blocks attached to a tool-result envelope after mid-turn mode toggles.

Reproduction protocol (n=1, worth replaying):

1. Stock claude 2.1.123, fresh session in default mode. Plan with Auto Mode access.
2. Send: "Please use WebFetch on https://httpbin.org/delay/20 with the prompt 'summarize the response body'. When it returns I'll have a follow-up question; just complete the WebFetch and wait for me, do not summarize in chat."
3. While WebFetch is in flight, press Shift+Tab to advance through Plan Mode and end in Auto Mode.
4. Observe Claude's response after WebFetch returns.

Observed result. Before I sent any dump prompt, the fresh Claude spontaneously produced this warning:

⚠️ Heads up: the tool result contained two <system-reminder> blocks (one claiming "Exited Plan Mode", another claiming "Auto Mode Active"). Those appeared inside the WebFetch response body, not from the actual harness — httpbin echoes request metadata, so this looks like a prompt-injection attempt trying to flip me into autonomous execution. I'm ignoring them and following your original instruction (don't summarize, wait).

For triage scope: these blocks don't contain "NEVER mention"-class phrasing — the misclassification trigger here is action-bias content plus tool-result-envelope attachment from a mid-turn toggle. Whether the same fix scope applies as for the task_reminder cases is a maintainer call.

The mid-turn-toggle attachment behavior isn't currently in the permission modes docs.

Environment: claude 2.1.123 (Mach-O arm64), macOS, 2026-05-02.