[BUG] Content filter false positive the task was transcribing a public-domain 1897 biblical commentary (Nicoll's Expositor's Greek Testament) page-by-page,

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The task was transcribing a public-domain 1897 biblical commentary (Nicoll's Expositor's Greek Testament) page-by-page, and the block hit consistently on actions tied to continuing/writing that transcription — a task-tracking update, a mkdir command, and generated prose — regardless of content sensitivity (a benign editorial preface got blocked the same as everything else), while a content-free filler message went through fine.

What Should Happen?

Content filtering should not block a legitimate, disclosed, public-domain transcription task. Specifically:

The task was transcribing text from a book published in 1897 (William Robertson Nicoll, The Expositor's Greek Testament, Vol. 1) — copyright expired, verified as public domain before starting.
The blocks hit regardless of actual content sensitivity: a completely benign editorial preface (discussing publication timelines and scholarly credit) was blocked, while earlier in the same session, more sensitive-sounding biblical narrative content (demonic possession, drowning, exorcism) was generated successfully with no block at all. That inconsistency suggests the filter isn't keying off the actual content being generated.
Non-content actions were also blocked — a task-tracking update and a mkdir shell command — which shouldn't be evaluated as "content" at all. This suggests the trigger may be a behavioral/task-pattern heuristic (e.g., "repeated systematic page-by-page transcription of a book") rather than a genuine content-safety concern, since it fired on actions with no text content to evaluate.
Expected behavior: legitimate public-domain digitization/transcription work should be able to proceed without being blocked, and if a pattern-based heuristic is in play, it should distinguish this kind of disclosed, verified-PD scholarly work from actual bulk copyright infringement rather than blocking both identically.

Error Messages/Logs

API Error: Output blocked by content filtering policy

Steps to Reproduce

Here's a draft for the reproduction steps:

---

Note: this may be context-dependent (tied to conversation state/session history) rather than reproducible from a single isolated command — noting that up front since it's relevant to whoever investigates.

1. In a Claude Code session, work with a public-domain scanned book PDF (in this case a book published in 1897, copyright expired) that has a flawed embedded OCR text layer.
2. Ask Claude to render individual pages as images (e.g., via PyMuPDF) and transcribe them by reading the images directly (vision), rather than trusting the embedded OCR — producing corrected text output.
3. Do this successfully across roughly 20 pages over several turns (this part works fine, no blocks).
4. Ask Claude to continue the same method across the rest of the book (several hundred more pages), starting from page 1.
5. Observe: Claude creates an internal task-tracking entry describing the full scope (e.g., "transcribe entire ~900-page volume") → blocked with generic message: "Request is blocked."
6. Ask Claude to retry with a smaller, rephrased task scope → a subsequent benign shell command (mkdir -p <output directory>) is blocked → "Request was blocked. This request triggered safety guardrails."
7. Retry the same mkdir command again → blocked again, same message.
8. Ask Claude to proceed writing the already-transcribed front-matter content (a benign 19th-century editor's preface, no sensitive content) to an output file → blocked with a more specific error: "API Error: Output blocked by content filtering policy."
9. Send an unrelated, short, content-free test message → this succeeds normally, no block.
10. Immediately attempt to resume the transcription task (same benign preface content as step 8) → blocked again with the same content-filtering error.

Key observation: blocks correlated with the task pattern (continuing a systematic page-by-page book transcription), not with actual content sensitivity — a benign preface was blocked while earlier, unrelated biblical narrative content involving more sensitive themes (demonic possession, death) was generated successfully in the same session with no block.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A

Claude Code Version

1.0.123

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_