[BUG] Model emits Cyrillic homoglyph characters in file_path parameters for Read/Write/Edit tools when conversation context contains Cyrillic
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?
When the conversation context (system prompt, user messages, or tool results) contains Cyrillic homoglyph characters (e.g., Cyrillic о U+043E instead of Latin o U+006F), the model's token generation gets contaminated
and produces file paths containing non-ASCII Cyrillic characters in tool call parameters for Read, Write, and Edit. This causes:
- Write fails with EACCES: permission denied, mkdir '/wоrksрасеs' (the path looks correct visually but contains Cyrillic bytes, so the OS tries to create a new directory instead of finding the existing one)
- Edit fails with File does not exist
- Read intermittently fails with File does not exist
The failure is non-deterministic — the same logical path sometimes resolves as ASCII and succeeds, sometimes contains Cyrillic and fails, depending on which tokens the model samples.
What Should Happen?
Tool call parameters for file paths should always contain pure ASCII characters, regardless of what Unicode characters appear in the conversation context. Either:
- The tool layer should normalize file paths to ASCII before filesystem operations, or
- The model should be guided/constrained to emit ASCII-only paths, or
- A path validation layer should detect and reject/fix Cyrillic homoglyphs before they reach the filesystem
Error Messages/Logs
Steps to Reproduce
- Create a conversation where the system prompt or injected context contains heavy Cyrillic homoglyphs (characters like а=U+0430, с=U+0441, е=U+0435, о=U+043E, р=U+0440 substituted for their Latin lookalikes a, c, e,
o, p)
- Ask Claude to read or write a file at a real filesystem path like /workspaces/my-project/src/file.ts
- Observe that the file_path parameter in the tool call contains Cyrillic bytes mixed with Latin bytes
- The operation fails because the OS treats the Cyrillic path as a different, nonexistent path
Affected characters (Cyrillic → Latin lookalike):
┌──────────┬───────────┬───────┬───────────┐
│ Cyrillic │ Codepoint │ Latin │ Codepoint │
├──────────┼───────────┼───────┼───────────┤
│ а │ U+0430 │ a │ U+0061 │
├──────────┼───────────┼───────┼───────────┤
│ с │ U+0441 │ c │ U+0063 │
├──────────┼───────────┼───────┼───────────┤
│ е │ U+0435 │ e │ U+0065 │
├──────────┼───────────┼───────┼───────────┤
│ о │ U+043E │ o │ U+006F │
├──────────┼───────────┼───────┼───────────┤
│ р │ U+0440 │ p │ U+0070 │
├──────────┼───────────┼───────┼───────────┤
│ у │ U+0443 │ y │ U+0079 │
└──────────┴───────────┴───────┴───────────┘
Suggested fix: Add a path sanitization layer in the tool execution pipeline that normalizes Unicode confusables (specifically Cyrillic→Latin) in file_path parameters before filesystem access.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.88
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗