[BUG] Cyrillic Homoglyph Characters Injected Into English Output During Long Sessions

Resolved 💬 1 comment Opened May 7, 2026 by shivansh052k Closed Jun 5, 2026

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:

  1. During compaction, the session summary was generated with redeплoys (mixed-script).
  2. This corrupted token was then treated as ground truth and reproduced verbatim in subsequent outputs — including a PR description written by the agent.
  3. 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:

  1. Run a long English-language coding session until context compaction is triggered.
  2. Inspect the compacted summary for any mixed-script tokens.
  3. 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.

View original on GitHub ↗

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