[Bug] Panic on UTF-8 multibyte character boundary in Japanese text
Status Fixed / completed
Maintainer reply ✓ Yes — ashwin-ant
Workaround ✓ Mentioned in thread ↓
Activity 14 comments · opened Dec 18, 2025 · closed Apr 18, 2026
💡 Likely answer: A maintainer (ashwin-ant, collaborator)
responded on this thread — see the highlighted reply below.
Description
Claude Code CLI panics when processing Japanese text that contains multibyte characters. The panic occurs when the code attempts to slice a string at a byte index that falls in the middle of a multibyte UTF-8 character.
Error Message
thread '<unnamed>' (2356591) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 23 is not a char boundary; it is inside 'ィ' (bytes 21..24) of `情報セキュリティ`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
[1] 78853 abort claudeAnalysis
The panic occurs because:
- Rust encodes strings in UTF-8
- The Japanese character 'ィ' spans 3 bytes (21-24)
- The code attempts to slice the string at byte index 23, which is in the middle of the character
- This causes an invalid slice operation and triggers a panic
Environment
- macOS Darwin 25.0.0
- Claude Code CLI (latest version)
Expected Behavior
The CLI should properly handle multibyte UTF-8 characters (Japanese, Chinese, emoji, etc.) and not crash when processing them.
Suggested Fix
Use character-aware string operations like char_indices() instead of direct byte indexing when slicing strings that may contain multibyte characters.
14 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Encountered the same issue.
Environment:
claude --resume --dangerously-skip-permissionsError:
This occurred when attempting to resume a conversation that contained Japanese text using the
--resumeflag.I can confirm this issue. I encountered the same panic 3 times today on Linux.
Error message:
thread '' (1230740) panicked at /rustc/.../library/core/src/str/mod.rs:833:21:
byte index 44 is not a char boundary; it is inside '。' (bytes 42..45) of ータが保存されていない可能性。
fatal runtime error: failed to initiate panic, error 5, aborting
Environment:
The panic occurred with the Japanese period character '。' (U+3002, 3 bytes in UTF-8).
This is a recurring issue that affects daily workflow for Japanese users. Looking forward to a fix.
Same issue in Korean too.
I'm also experiencing this issue.
Environment:
Error message:
thread '' panicked at /rustc/.../library/core/src/str/mod.rs:833:21:
byte index 8 is not a char boundary; it is inside '数' (bytes 6..9) of 項目数</CardTitle>
fatal runtime error: failed to initiate panic, error 5, aborting
zsh: abort claude --dangerously-skip-permissions
Context:
Running multiple agents in parallel while processing JSX/TSX files containing Japanese text (React components with Japanese labels).
I encountered the same issue with a slightly different pattern.
Additional Reproduction Case
The crash also occurs with full-width parentheses
（）in Japanese text:Context
8,000文字（約1%）しか使用していない(meaning "only 8,000 characters (about 1%) are being used")（）are each 3-byte UTF-8 charactersEnvironment
Workaround
Closing the file in the IDE before starting Claude Code avoids the crash.
I'm also experiencing this issue on Linux.
Environment:
Additional symptom:
In addition to crashes, I'm seeing character corruption where similar-looking kanji are incorrectly substituted. For example:
Both characters share the same first 2 bytes in UTF-8 (E7 AE), suggesting the byte boundary slicing may be corrupting the third byte.
This appears to be a related manifestation of the same underlying bug.
This issue seems to be related to https://github.com/anthropics/claude-code/issues/14104 .
Additional reproduction case from Japanese user
Environment:
Reproduction scenario:
Editing HTML files containing Japanese text. The crash occurs with both
EditandWritetools.Error logs (4 separate crashes in one session):
Impact:
This bug makes Claude Code unusable for editing Japanese HTML/Markdown files. Simple text replacement operations (e.g., renaming "CAA-Agent" to "AIエージェントエンジニア認定資格") cause repeated crashes, forcing users to abandon the task or use external tools.
Workaround attempted:
sedvia Bash tool, which bypasses the problematic string handlingThis is a critical issue for Japanese (and likely all CJK) users.
Experiencing the same issue on WSL2
All crashes occurred while editing files containing Japanese text—not only large Markdown tables, but also regular text with CJK characters. Every edit attempt is a gamble.
I never experienced this issue when using the npm version. The crashes started after switching to the native Rust binary.
This is a significant blocker for daily work. The official docs state that "the native installation is the recommended method," yet CJK users are essentially unable to use it reliably.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
Update: v2.1.49 - Silent character substitution instead of crash
The crash appears to be fixed in v2.1.49, but I'm now observing silent character corruption in AskUserQuestion tool output — no panic, just wrong kanji.
Environment:
Confirmed example (captured live in this session):
再現樹証(樹 = U+6A39)再現検証(検 = U+691C)长期(U+957F, simplified Chinese) instead of長期(U+9577, Japanese)Pattern:
AskUserQuestionoption strings generated by the modelclaude-sonnet-4-6; not yet confirmed withclaude-opus-4-6Hypothesis:
The crash fix in later versions may have addressed the panic but left silent byte-level corruption as a side effect. The substituted characters (e.g. 検→樹, 長→长) share partial UTF-8 byte sequences, suggesting the underlying byte boundary issue persists but no longer triggers a fatal panic.
Previously reported in this thread (2025-12-31): character corruption 箇(U+7B87)→箱(U+7BB1), same first 2 UTF-8 bytes (E7 AE).
This regression makes the bug harder to detect since there's no visible crash — corrupted output is silently accepted.
This was fixed in v2.1.6 — Diff rendering no longer panics on multibyte (CJK) character boundaries; the underlying native module has been replaced with a pure-TypeScript implementation. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.
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.