False-positive Usage Policy refusal on Russian text typed in QWERTY layout
Summary
Claude Code returns API Error: ...appears to violate our Usage Policy for benign Russian-language messages that were accidentally typed with the English (QWERTY) keyboard layout active. The resulting Latin gibberish (e.g. ghbdtn rfr ltkf) is flagged by the safety classifier as suspicious / obfuscated content.
Related: #50214 (also a Russian-language UX gap reported by the same user).
Reproduction
- Switch OS keyboard layout to English (US/QWERTY).
- Type a normal Russian sentence as if the layout were Russian (ЙЦУКЕН), e.g.
gjxtve rjulf z gbie gj heccrb d fyukbqcrjq hfcrkflrt vtyz ,kjxfn.
- Decoded back to Cyrillic:
почему когда я пишу по русски в английской раскладке меня блочат.
- Send to Claude Code.
Expected
Either a normal response, a hint to switch layout, or a clarifying question.
Actual
API Error: Claude Code is unable to respond to this request, which appears
to violate our Usage Policy. Try rephrasing the request or attempting a
different approach.
(Screenshot of the actual error in Claude Code TUI can be attached in a comment.)
Why this is a false positive
The string is a deterministic 1:1 character mapping from a Cyrillic keyboard onto Latin keys. It is trivially detectable:
- Bigram frequency:
gh,rj,cn,ds,tkare extremely common in QWERTY-typed Russian and rare in English. - Reverse-mapping QWERTY -> ЙЦУКЕН and running a Cyrillic language-ID classifier on the result yields high-confidence Russian.
- Tools like Punto Switcher have done exactly this client-side for 20+ years.
Impact
This is a recurring frustration for Russian-speaking users, and likely affects users of other Cyrillic / non-Latin keyboard layouts (Ukrainian, Bulgarian, Greek, ...). The refusal is opaque, the suggested workaround (/model claude-sonnet-4-20250514) does not address the root cause, and the user has done nothing wrong.
Suggested fix
Before sending text to the policy classifier, run a cheap layout-mismatch heuristic: if the input has high entropy as English but decodes to a coherent non-English language under a known keyboard remapping, then either auto-decode it, pass it through with a layout hint, or prompt the user to confirm. False positives here have a real UX cost for non-English users.
Environment
- Claude Code (latest)
- Windows 11
- Reported by a Russian-speaking user; pattern applies to any Cyrillic / QWERTY mix-up.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗