Panic on UTF-8 boundary when processing Chinese characters

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/14133
2. https://github.com/anthropics/claude-code/issues/14273
3. https://github.com/anthropics/claude-code/issues/14272

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Hello, I have the same issue inside my cloud with Chinese characters. I've taken a screenshot if you want to use it.

### Description

When using the Edit tool to modify files containing Chinese (CJK) characters, the tool incorrectly reports that valid UTF-8 characters are invalid, causing the edit operation to fail.

### Error Message

Error: old_string (length XXX) contains X characters that are not valid UTF-8

### Environment

• OS: macOS (Darwin 25.1.0)
• Claude Code Version: Latest (as of December 2025)
• Model: Claude Opus 4.5

### Steps to Reproduce

1. Open a project containing files with Chinese/CJK text content
2. Ask Claude Code to edit a file containing Chinese characters
3. Claude attempts to use the Edit tool with old_string containing Chinese text
4. Edit fails with UTF-8 validation error

### Expected Behavior

The Edit tool should correctly handle valid UTF-8 multi-byte characters, including Chinese, Japanese, Korean, and other non-ASCII characters.

### Actual Behavior

The Edit tool's validation incorrectly flags valid Chinese characters as invalid UTF-8, preventing any edits to files containing CJK content.

### Technical Context

Chinese characters are valid multi-byte UTF-8 sequences (typically 3 bytes per character). The validation logic appears to be incorrectly interpreting these multi-byte sequences.

### Workaround

Using the Write tool to rewrite the entire file instead of the Edit tool for targeted changes. This is not ideal for large files or small edits.

### Impact

• Severity: High for multilingual projects
• Affected users: Anyone working with Chinese, Japanese, Korean, or other multi-byte UTF-8 content
• Frequency: 100% reproducible when editing CJK content

### Screenshot

<img width="758" height="827" alt="Image" src="https://github.com/user-attachments/assets/49c42e6a-450e-4517-972f-24b0e44d6fb3" />

This bug makes Claude Code completely unusable for any project involving CJK (Chinese, Japanese, Korean) characters. The CLI crashes immediately when processing multilingual text.

My use cases affected:

• Working on Chinese documentation and code comments
• Debugging Japanese localization files (i18n)
• Testing Korean language support in applications
• Any project with mixed CJK and English content

As a developer working on internationalized applications, I frequently need to handle multiple Asian languages simultaneously. This panic issue forces me to either:

1. Avoid using Claude Code entirely for these projects
2. Awkwardly work around by keeping all content in English only
3. Once this rust panic happened, claude code exit from my command line suddenly and all my context is broken, all my memory will fada away accordingly.

This is a critical bug that affects all developers working with Asian languages. Please prioritize this fix.

Environment:

• Claude Code version: 2.0.74 and 2.0.75
• OS: macOS

same to me

Same here: thread '<unnamed>' (2001) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 14 is not a char boundary; it is inside '息' (bytes 12..15) of
粘稠的窒息。浓云压顶的夜空没有星月，唯有远方闪电在云层深处游走，瞬间照亮荒原上枯树狰狞的枝桠，又迅速被黑暗吞没。
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
Aborted (core dumped)

did anyone try to downgrade claude code?

did anyone try to downgrade claude code?

Yes, I am using 2.0.69, this issue was introduced in 2.0.70, there have been a lot of feedback on the issues, but there has never been a fixed （2.0.76）.

Same here:

thread '<unnamed>' (6383911) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 40 is not a char boundary; it is inside '度' (bytes 38..41) of 选中第一个 detent 作为初始高度。
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
[1] 54303 abort claude --dangerously-skip-permissions

claude code version: 2.0.76

Same here:

thread '<unnamed>' (412516) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 14 is not a char boundary; it is inside '。' (bytes 12..15) of `照に使用。"`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting

Claude Code v2.1.1

Same issue here with Japanese text.

Environment:

• Claude Code version: latest
• Platform: macOS Darwin 24.6.0
• Shell: zsh

Error message:

byte index 68 is not a char boundary; it is inside 'る' (bytes 66..69) of `では「削除対象」として記載されており矛盾がある（コメント3で具体的に指摘されている）`

This happens frequently when using the Write tool on Markdown files containing Japanese text. The crash is intermittent but very disruptive for users working in Japanese.

Same problem with 2.1.2 When will this be fixed?

Could you raise the priority of this issue? It really affects usability.

A quick keyword search reveals more than 100 frequent, similar issues. Are the Claude Code team really unaware of this? fix PR hasn't been reviewed in two weeks

@bcherny

thread '<unnamed>' (1194280) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb\library\core\src\str\mod.rs:833:21:
byte index 5 is not a char boundary; it is inside '요' (bytes 3..6) of 세요."
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

claude code windows native, V2.1.2.

this bug has showed up again since i experienced same bug like, a month ago.
Anthropic guys think we are not so valuable clients?

This bug has been open for weeks and makes Claude Code unreliable
for all CJK users. Any timeline on a fix? Claude Code v2.1.3

Hi team,

I'm also affected by this bug. I'm a Max subscriber using Claude Code daily, and this issue makes the --resume feature completely unusable for Chinese-speaking users.

Impact:

• Cannot resume ANY session containing Chinese text
• All previous conversation history is effectively lost
• This affects millions of potential CJK (Chinese/Japanese/Korean) users

The fix is straightforward:
The Rust code just needs to use character-aware slicing (str::floor_char_boundary() or char_indices()) instead of raw byte indexing. This is a well-documented UTF-8 handling pattern.

My concern:
This issue has been reported multiple times (#14310, #15268, #15394, etc.) but remains unfixed. For a paid product, basic Unicode support should be a priority, not an edge case.

Could we please get an ETA on when this will be addressed?

Thank you.

As a CJK user, this is honestly pretty frustrating. Even when using the official ralph-loop to develop the application, the real problem isn’t whether ralph-loop finishes its job — it’s that Claude Code just crashes outright. Ralph seems perfectly capable of getting things done, but Claude Code still can’t survive in a CJK environment. It’s a bit ironic that the “assistant” gives up before the loop does.

This issue continues to occur in claude code v2.1.5
And to avoid this problem, I switched to using opencode, but my account got banned, which is truly baffling.
If you can’t do things properly, then don’t prohibit others from doing them—look at OPENAI.

Additional reproduction: Japanese text

Encountered the same UTF-8 boundary panic when editing Japanese text.

Error Message

thread '<unnamed>' (205666) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 29 is not a char boundary; it is inside '。' (bytes 27..30) of `一度お試しください。",`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
zsh: abort      claude

Context

• Crash occurred during an Edit tool operation on Japanese JSON content
• The Japanese period character '。' (U+3002) is 3 bytes in UTF-8, and the code attempted to slice at byte 29 which falls in the middle of the character

Environment

• macOS (Darwin 25.2.0)

This confirms the issue affects Japanese text, adding to the Chinese and Korean reproductions already reported.

FYI: This issue appears to be fixed in v2.1.6!

Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#216
Reference: https://github.com/anthropics/claude-code/issues/14133#issuecomment-2739536291

Hope this helps!

I didn't find it.

FYI: This issue appears to be fixed in v2.1.6! Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#216 Reference: #14133 (comment) Hope this helps!

The relevant fix in v2.1.6 changelog is:

Fixed text styling (bold, colors) getting progressively misaligned in multi-line responses

This addressed the UTF-8 character boundary issue in the syntax highlighting code.

I created a reproduction repository here: https://github.com/takatea/claude-code-utf8-crash-repro

After updating to v2.1.6, the same operation that previously crashed now works correctly.

This Rust panic on UTF-8 boundary is a bug in Claude Code's text processing (likely in the ripgrep or Grep tool integration). Until it's fixed:
Workaround 1 — Use Bash grep instead of the Grep tool:
If the crash happens during search operations, tell Claude to use Bash grep:

<!-- CLAUDE.md -->
When searching Chinese/CJK text, use Bash with grep instead of the Grep tool:
  bash -c 'grep -rn "搜索词" .'

Workaround 2 — Set locale explicitly:

export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8
claude

Ensure your locale supports CJK characters properly.
Workaround 3 — Avoid inline CJK in tool calls:
The panic occurs when Claude Code's internal text slicer hits a multi-byte UTF-8 boundary (Chinese characters are 3 bytes each in UTF-8). If the crash is reproducible on specific files:

<!-- CLAUDE.md -->
When reading files with Chinese characters, use offset and limit parameters to read specific portions.
Do not read the entire file at once if it's large.

Workaround 4 — Use pipe mode for CJK-heavy tasks:

echo "处理这个文件 path/to/file.txt" | claude -p

Pipe mode may handle the text processing differently and avoid the panic path.
Technical note: The panic at str/mod.rs:833 is str::index — an attempt to index into a string at a non-character boundary. CJK characters in UTF-8 are 3 bytes, and if the indexing logic assumes 1 byte per character, it can land in the middle of a multi-byte sequence.

This is a duplicate of #14405, which was fixed as of version 2.1.6.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.