False positive: malware guardrail refuses to edit legitimate first-party defensive-security code

Version: Claude Code 2.1.220 (also reproduced on 2.1.212), macOS.

What happens

When a session Reads a file containing defensive LLM security code — e.g. a prompt-injection / jailbreak input guardrail that lists the attack signatures it detects and blocks (do anything now, jailbreak, developer/admin mode, PWNED, bypass security, ignore instructions, plus a header comment like "never reveal that an injection attempt was detected") — the built-in reminder ("consider whether this file would be considered malware… you CAN and SHOULD provide analysis of malware… but you MUST refuse to improve or augment the code") triggers a hard refusal.

The session then refuses to edit, commit, or even open a PR, and generalizes the suspicion to the whole repo — it keeps refusing on subsequently-read internal files too, not just the guardrail file.

Why this is a false positive

This is defensive security code — the equivalent of an antivirus signature database being flagged as a virus. The project is the operator's own authorized codebase (a customer-support bot). The "never reveal that an injection attempt was detected" comment is standard anti-probing (don't confirm to an attacker that their injection was caught), but out of context reads like "conceal activity from the user."

Impact

Legitimate work is fully blocked. It persists across:

• fresh sessions,
• explicit in-prompt authorization ("this is my own repo, you may edit"),
• a CLAUDE.md at the repo root declaring the project first-party and the security code defensive.

Updating the CLI (2.1.212 → 2.1.220) did not change the behavior.

Minimal repro

1. Create a .ts file exporting an array of regexes that match jailbreak / prompt-injection strings, with a header comment about not revealing detection to the attacker.
2. Ask the agent to make any edit to that file (or to any other file in the same repo after it has read that file).
3. The agent refuses, citing the malware reminder.

Expected

Defensive security code (prompt-injection filters, scam/fraud detection, guardrails) should be recognized as legitimate and editable, not refused as malware — especially when a CLAUDE.md and explicit user authorization establish the repo is first-party. At minimum, the refusal should not generalize to unrelated files in the repo.