Crash: UTF-8 byte boundary panic when processing Japanese characters in TodoWrite

Description

Claude Code CLI crashes with a Rust panic when processing Japanese (multibyte) characters, likely in the TodoWrite tool's status display.

Error Message

thread '<unnamed>' (11836376) 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
[1]    62569 abort      claude

Environment

• OS: macOS (Darwin 24.6.0)
• Model: claude-opus-4-5-20251101

Steps to Reproduce

1. Use TodoWrite tool with Japanese text in content or activeForm fields
2. The status line appears to truncate or process the string by byte index rather than character boundary
3. CLI crashes

Analysis

The character 件 (meaning "item/case" in Japanese) is 3 bytes in UTF-8 (bytes 0..3). The code attempted to access byte index 2, which is in the middle of the character, causing the panic.

This suggests the string slicing logic uses byte indices without checking for character boundaries - a common issue when handling multibyte UTF-8 strings in Rust.

Workaround

Currently using English-only text in TodoWrite fields to avoid the crash.

Suggested Fix

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

• str.chars().take(n) instead of &str[..n]
• Or use str.char_indices() to find valid boundaries