CLI crashes when editing files containing Japanese text (UTF-8 boundary error)

Bug Description

Claude Code CLI crashes when attempting to edit a Markdown file containing Japanese text with multi-byte UTF-8 characters.

Error Message

thread '<unnamed>' panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 4 is not a char boundary; it is inside '字' (bytes 3..6) of `文字（約1%）しか使用していない`
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

Steps to Reproduce

1. Open a Markdown file containing Japanese text in an IDE (VS Code)
2. Start Claude Code CLI
3. Request Claude to edit the file

The file contains Japanese text with full-width parentheses. For example:

• The string in the error message translates to: "characters (about 1%) are being used"
• Full-width parentheses （） are 3-byte UTF-8 characters
• Japanese kanji like 字 (meaning "character") are also 3-byte UTF-8 characters

Root Cause Analysis

The Rust code appears to be slicing a UTF-8 string at a byte index that falls within a multi-byte character boundary. In Rust, string slicing must occur at valid UTF-8 character boundaries.

For example, the character 字 occupies bytes 3-6, but the code is attempting to slice at byte index 4, which is inside this character. This causes a crash because Rust enforces UTF-8 validity at slice boundaries.

Environment

• Claude Code version: v2.0.76
• Model: Opus 4.5
• OS: macOS (Darwin 23.6.0)
• Platform: darwin arm64

Workaround

Closing the file in the IDE before starting Claude Code may avoid the crash.

Expected Behavior

Claude Code should properly handle multi-byte UTF-8 characters (Japanese, Chinese, Korean, emoji, etc.) without crashing. The string slicing logic should use character boundaries instead of raw byte indices.