[BUG] Cyrillic Homoglyph Characters Injected Into English Output During Long Sessions
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?
During a long-running English-language session, the agent produced output containing mixed-script text — specifically, Cyrillic characters embedded within what should have been a plain ASCII/Latin English word:
[...] when combined with --rotate-keys, immediately redeплoys all READY PR preview deployments [...]
The word redeплoys contains Cyrillic п (looks like Latin p) and л (looks like Latin l). These are homoglyphs — characters from a different Unicode block that are visually nearly indistinguishable from their Latin counterparts at a glance.
---
Root Cause (Agent's Self-Analysis)
When prompted to investigate, the agent identified the likely origin as the context compaction / session summary step:
"It looks like it crept in via the session summary (the compressed context uses the same spelling), and I propagated it into both my text output and the PR description without catching it."
In other words:
- During compaction, the session summary was generated with
redeплoys(mixed-script). - This corrupted token was then treated as ground truth and reproduced verbatim in subsequent outputs — including a PR description written by the agent.
- Neither the agent nor the user caught it visually, since the Cyrillic homoglyphs are nearly pixel-perfect matches for their Latin equivalents.
---
Why This Is Serious
- Silent corruption: The output looks correct to the naked eye but is semantically wrong at the character level — tools doing string matching, search, grep, or copy-paste will behave unexpectedly.
- Propagation risk: Once a corrupted token enters the compacted context summary, it gets re-injected into every subsequent turn of the session, silently spreading the corruption.
- PR/document poisoning: In this case, the corrupted text was written directly into a pull request description, meaning the bug escaped the terminal entirely.
- No error or warning was raised at any point — neither by the agent nor by the runtime.
What Should Happen?
- The agent should produce only Latin characters when generating English-language output.
- The compaction/summarization step should not introduce mixed-script tokens into the session context.
- Ideally, a validation pass (or at minimum, a warning) should detect non-ASCII homoglyphs appearing in otherwise ASCII contexts.
Error Messages/Logs
Steps to Reproduce
Unknown — occurred spontaneously during a long-running session. Suspected trigger is the automatic context compaction step in extended sessions.
Potential avenue for reproduction:
- Run a long English-language coding session until context compaction is triggered.
- Inspect the compacted summary for any mixed-script tokens.
- Continue the session and observe whether corrupted tokens are reproduced in subsequent output.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.131 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
- Cyrillic
п(U+043F) andл(U+043B) are the specific characters observed. - The corruption was confirmed by the agent itself upon inspection: "What we saw was output corruption — Cyrillic
пandлappeared in text Claude generated (specifically in the session context summary, then propagated into my responses)." - A Unicode script-consistency check on compacted summaries may be a low-cost mitigation.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗