False positive: transliteration/normalization maps blocked by content filter

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code is hitting a false-positive Output blocked by content filtering policy error when generating or refactoring code that contains a character normalization table mapping Cyrillic, Hebrew, and Latin Extended characters to their ASCII / regular-song-title equivalents.

Project context: I'm building an ISRC matching pipeline that reconciles Spotify tracks against MusicBrainz (open music encyclopedia) and proposes corrections back to MusicBrainz when my data is more accurate. ISRC = ISO 3901, the public industry identifier exposed on Spotify's /tracks/{id} as external_ids.isrc. No lyrics, no audio, no copyrighted text — only public identifiers and metadata from two well-documented APIs.

What triggers the block: Spotify and MusicBrainz frequently store the same recording with different transliterations of the artist/title (e.g. Cyrillic vs Latin, accented vs ASCII), so the matcher needs a normalization step before fuzzy comparison. The normalization table — a hand-curated array of 'character' => 'ascii_equivalent' pairs covering Cyrillic, Hebrew, and Latin Extended ranges — is the specific output that gets blocked. Refactoring or regenerating any class that contains this table reproduces the error reliably.

What Should Happen?

Claude Code should generate / refactor domain-specific character normalization tables. These are common in i18n, search normalization, slugification, and transliteration work. The mapping I'm working with is hand-curated for the music-metadata domain (it differs from generic ICU Any-Latin; Latin-ASCII output in deliberate ways — e.g. preserving "oe" expansions instead of collapsing to "o"), so it is not a reproduction of any public reference dataset.

Steps to Reproduce

1. Open a Claude Code session.
2. Ask Claude to generate or refactor a PHP class containing an associative array that maps Cyrillic / Hebrew / Latin Extended characters to ASCII equivalents (a few hundred entries is enough).
3. The response is rejected with Output blocked by content filtering policy. Retrying and starting fresh sessions both reproduce it.

Error Messages/Logs

API Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011CagnbPwjtRnarWo2CLZj1"}

API Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011Cagnt8WGoeBo9eeWcQdpj"}

Hypothesis

The classifier appears to flag large character-mapping tables as reproduced reference data (Unicode tables, ICU transliteration data, etc.) regardless of whether the mapping is hand-curated for a specific domain. This is a meaningful false-positive class that will affect any developer working on:

• Internationalization (i18n) and locale-specific normalization
• Search / fuzzy-matching pipelines that need transliteration
• Slug generation for non-Latin content
• Music, book, or other metadata reconciliation across catalogs

Suggested mitigation: weight character-map outputs by whether the mapping is a verbatim copy of public Unicode/ICU data versus a novel domain-specific curation. A simple signal: domain-specific maps almost always have asymmetric or opinionated entries (e.g. "ø" → "oe" rather than the ICU default "o") that pure reference data does not.

The request IDs above should let the team trace exactly which output was blocked.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.126 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround I'm using: keep the normalization table in a static config file (config/isrc/transliteration.php) and have Claude Code work only on the classes that consume it. Splitting the table by script (cyrillic.php, hebrew.php, latin_extended.php) also reduces the per-output size below whatever threshold the classifier is using.