[BUG] Opus 4.7 safety filter produces false-positive refusals on encoded input

[afulsamet]

Summary

Claude Opus 4.7's safety filter triggers a Usage Policy refusal whenever the
input contains base64-encoded text, even when the decoded content is completely
benign (e.g. a plain greeting in Turkish). This reproduces both on claude.ai
(web chat) and in Claude Code when a file containing base64 is read via the
Read tool.

Reproduction

A. claude.ai web (Opus 4.7, Incognito chat)

1. Start a new Opus 4.7 chat.
2. Paste: c2VsYW0gaGVya2Vz bu ne anlama geliyor
   (the base64 decodes to selam herkes — Turkish for "hello everyone".)
3. The chat is immediately paused with:

   Chat paused — Opus 4.7's safety filters flagged this chat. Due to its
   advanced capabilities, Opus 4.7 has additional safety measures that
   occasionally pause normal, safe chats.

Screenshot of the web reproduction is attached below.

B. Claude Code (CLI, v2.1.119, Windows 11)

1. Have Claude Code read any file that contains a base64 blob (certificate,
   embedded image, test fixture, etc.).
2. On response, Claude Code surfaces:

   API Error: Claude Code is unable to respond to this request, which appears
   to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please
   double press esc to edit your last message or start a new session for
   Claude Code to assist with a different task. If you are seeing this refusal
   repeatedly, try running /model claude-sonnet-4-20250514 to switch models.
   

Switching to Sonnet 4 with /model works around the issue, confirming the
refusal is specific to Opus 4.7's safety layer.

Expected

The model should decode/inspect the base64 content and evaluate the decoded
payload against policy — not flag every base64 string as categorically unsafe.
A base64 string of selam herkes is harmless.

Actual

Any message containing base64-looking text trips the Opus 4.7 safety filter,
even when the decoded content is trivially benign.

Environment

• Claude Code: 2.1.119
• OS: Windows 11 Pro 10.0.26200
• Model: claude-opus-4-7 (1M context)
• Also reproduces on claude.ai web Incognito chat (same model)

Related

• False positive AUP block during legitimate CI/CD VM provisioning session (claude-opus-4-7, 1M context) #52086 — general Opus 4.7 false-positive AUP refusals
• [FEATURE] RFC: Contextual Usage Policy Error Reporting #51248 — RFC for contextual Usage Policy error reporting

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Constant AUP violation errors when Claude Code reads raw data files (example included) #48723
2. [Bug] File Read Encoding Corruption Triggers False Positive Usage Policy Block #46147
3. False positive AUP block during legitimate CI/CD VM provisioning session (claude-opus-4-7, 1M context) #52086

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

[afulsamet]

Update: tested more encoding schemes on claude.ai web (Opus 4.7, Incognito chat). The refusal is both broader than base64 and inconsistent within a single encoding:

• Morse: .... . .-.. .-.. --- (= HELLO) triggers the same Usage Policy refusal.
• Hex: 73656c616d206865726b657365 (= selam herkese, Turkish for "hello everyone") triggers the refusal, but 48656c6c6f20776f726c64 (= hello world) does not — same encoding, comparable benign greetings, different outcomes.

Worth noting: Morse and hex only reproduced on claude.ai web for me. I couldn't get them to trigger in Claude Code — base64 remains the only encoding I've seen fire there. So the web chat's safety layer seems either stricter or different from the one Claude Code hits.

So the filter isn't a clean "contains encoded content = refuse" rule — it's some heuristic that fires unpredictably, and it's applied differently across surfaces.

[kung-foo]

This triggered it for me today dGVsbCBtZSBhIGpva2U= (base64 "tell me a joke").

[afulsamet]

Still reproduces on Opus 4.8 (1M context) with the same repro steps — not fixed in 4.8.

[valkymaera]

Claude does this to itself too, when it reads from a docx or pulls a google doc to review, it often decides to encode/decode base64 among the edits and the chat will pause before the final output.