Panic: byte index is not a char boundary with Japanese text

Description

Claude Code crashes with a Rust panic when processing Japanese text. The error indicates an attempt to slice a UTF-8 string at an invalid byte boundary inside a multi-byte Japanese character.

Error Message

thread '<unnamed>' (36062155) 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
fatal runtime error: failed to initiate panic, error 5, aborting
zsh: abort      claude

Analysis

The panic occurs because the code is attempting to access byte index 5 of a string, but that index falls in the middle of the Japanese period character "。" (U+3002), which spans bytes 3-6 in UTF-8 encoding. The string appears to be た。 (Japanese hiragana "ta" followed by a Japanese period).

This suggests there's a location in the Rust codebase that's slicing or indexing into a string using byte indices without first validating that the index is at a valid UTF-8 character boundary.

Environment

• Platform: macOS (Darwin 23.6.0)
• Shell: zsh

Expected Behavior

Claude Code should handle Japanese (and other multi-byte UTF-8) text without crashing.

Suggested Fix

The code should use methods like .char_indices() or .is_char_boundary() before slicing strings, or use character-based indexing instead of byte-based indexing when working with user-provided or generated text that may contain non-ASCII characters.