Korean character handling causes panic (UTF-8 boundary error)

Bug Description

Claude Code CLI panics when processing Korean characters in status line or command output.

Error Message

thread '<unnamed>' (752852) 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

Analysis

The Rust code is attempting to slice a string at byte index 2, but this falls in the middle of the Korean character '로' (which spans bytes 0-3). Korean characters in UTF-8 typically use 3 bytes each.

The string 로 정리 breaks down as:

• 로 = bytes 0-2
• = byte 3
• 정 = bytes 4-6
• 리 = bytes 7-9

Slicing at byte 2 breaks the UTF-8 encoding.

Frequency

This crash occurs multiple times per day when working with Korean text in:

• File operations
• Status line updates
• Command descriptions
• Todo/task tracking

Environment

• Platform: macOS (Darwin 24.3.0)
• Claude Code version: Latest
• Command used: claude --dangerously-skip-permissions

Expected Behavior

String slicing operations in the CLI should use character boundaries rather than byte indices, or validate UTF-8 boundaries before slicing.

Suggested Fix

Use .char_indices() or .chars().take(n) instead of direct byte index slicing, or validate with .is_char_boundary() before slicing.

Reproduction

1. Use Claude Code with Korean characters in any context
2. Perform file operations or status updates
3. CLI crashes with UTF-8 boundary panic

Impact

This makes Claude Code nearly unusable for Korean-speaking developers, requiring constant workarounds (English-only mode) and causing data loss from interrupted operations.