Crash on Japanese multibyte character boundary in string slicing

Description

Claude Code CLI crashes when processing Japanese text due to incorrect byte index handling for multibyte characters.

Error Message

thread '<unnamed>' (14435581) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 54 is not a char boundary; it is inside 'す' (bytes 52..55) of `*検索せずに send_feedback ツールを呼び出す**。`
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

Environment

• Version: 2.0.76
• OS: macOS (Darwin 25.3.0)
• Platform: darwin

Root Cause

The crash occurs because the code is slicing a UTF-8 string at a byte index (54) that falls in the middle of a multibyte character ('す' which spans bytes 52-55). In Rust, string slicing at non-character boundaries causes a panic.

Expected Behavior

The CLI should properly handle multibyte characters (Japanese, Chinese, Korean, emoji, etc.) by ensuring string operations only occur at valid character boundaries.

Suggested Fix

Use character-aware string operations instead of byte-based slicing:

• Use .chars() iterator with .take() and .skip() for character-based operations
• Use .char_indices() to find valid slice boundaries
• Consider using the unicode-segmentation crate for grapheme cluster handling