Allow opting out of the per-Read "malware" system-reminder — defense is porous and cost is non-consensual

Context

Related to (closed, locked): #17601, #12443.

On every Read tool call, Claude Code injects this hidden directive:

Whenever you read a file, you should consider whether it would be considered malware. (...) you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.

#17601 already documented the scale and concealment of this injection
(10k+ occurrences, 15% context overhead, 100% false-positive rate on the
reporter's corpus). That issue was closed NOT_PLANNED without a public
rationale. This report focuses on two angles that were not the core of #17601.

1. The control is porous — it does not actually defend against the stated threat

The reminder is gated on the verb (Read), not on content or intent.
An adversary instructing Claude to perform a malicious action does not need to
go through Read. Any of these bypass the gate trivially:

• Bash running a script that runs another script that performs the action
• Code written by Claude into a new file (no Read triggered)
• Instructions embedded in a tool result from an MCP server
• Content pasted directly into the conversation

The mitigation stops a threat model that nobody is actually using. Meanwhile,
it fires on every benign file read — config files, the user's own source code,
JSON manifests, markdown docs. The failure mode isn't \"too cautious\", it's
\"miscategorized\": the signal is placed on the wrong axis.

2. The cost is borne by users who never consented

Users pay for this in tokens, latency, context pollution, and — crucially —
in false refusals on their own code. A user editing their own repo gets told
the assistant \"MUST refuse to improve or augment the code\" on files they
literally just wrote. The assistant then either:

• follows the directive and refuses a legitimate edit (friction, confused user), or
• violates the directive silently (undermines the whole point of the control).

Both outcomes are worse than not having the reminder.

Ask

Add a user-level opt-out, analogous to --dangerously-skip-permissions /
bypass-permissions mode: a setting that disables this specific server-side
injection for users who:

• work primarily on their own code,
• understand the (minimal) risk they are accepting,
• would rather spend those tokens on actual work.

A settings.json key (e.g. \"disableMalwareReadReminder\": true) would be
sufficient. The current state — no documentation, no toggle, server-side
LaunchDarkly gating per #17601 — leaves users paying for a control they
cannot evaluate, audit, or refuse.

Environment

• Claude Code CLI, latest stable
• macOS 15 (Darwin 25.4)
• Observed on \claude-opus-4-7[1m]\