False-positive Usage Policy refusal on Russian text typed in QWERTY layout

Resolved 💬 1 comment Opened Apr 25, 2026 by Dmitriy-Kondratev Closed May 29, 2026

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

  1. Switch OS keyboard layout to English (US/QWERTY).
  2. 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: почему когда я пишу по русски в английской раскладке меня блочат.
  1. 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, tk are 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗