Panic on Korean (UTF-8 multibyte) text processing

Description

Claude Code crashes with a Rust panic when processing Korean text. The crash occurs because the code attempts to slice a UTF-8 string at an invalid byte boundary.

Error Messages

Case 1

thread '<unnamed>' panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 2 is not a char boundary; it is inside '는' (bytes 0..3) of `는 `## Next Steps` |`
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

Case 2

thread '<unnamed>' panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 2 is not a char boundary; it is inside '토' (bytes 0..3) 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

Environment

• Claude Code version: 2.1.5 (latest)
• OS: macOS (Darwin 25.2.0)
• Platform: darwin arm64

Root Cause Analysis

Korean characters (Hangul) are encoded as 3 bytes in UTF-8. The panic occurs because:

• Character 는 occupies bytes 0..3
• Character 토 occupies bytes 0..3
• Code attempts to slice at byte index 2, which is the middle of these characters
• Rust's string slicing correctly panics on invalid UTF-8 boundaries

Impact

• Claude Code becomes unusable for Korean-speaking users
• The CLI aborts completely, losing conversation context
• Likely affects other multibyte UTF-8 languages (Chinese, Japanese, emoji, etc.)

Suggested Fix

Use character-aware string operations instead of byte-based slicing. In Rust, use .chars() iterator or char_indices() for proper Unicode handling.