Panic on UTF-8 character boundary when processing Chinese filenames

[tytsxai]

Bug Description

Claude Code CLI crashes with a Rust panic when processing files with Chinese characters in their names.

Environment

• Claude Code Version: v2.0.76
• OS: macOS
• Shell: zsh

Error Message

thread '<unnamed>' (827689) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 20 is not a char boundary; it is inside '量' (bytes 18..21) of `配置与环境变量.md`
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 --permission-mode dontAsk

Steps to Reproduce

1. Have a file with Chinese characters in its name (e.g., 配置与环境变量.md)
2. Run Claude Code CLI with --permission-mode dontAsk
3. Perform operations that reference the file (e.g., documentation review, file editing)

Root Cause Analysis

The panic occurs at core/src/str/mod.rs:833:21 which indicates the code is trying to slice a UTF-8 string at byte index 20, but this index falls in the middle of the multi-byte character '量' (which occupies bytes 18-21).

This is a classic UTF-8 handling issue where the code uses byte indices instead of character boundaries when processing strings containing multi-byte characters.

Expected Behavior

Claude Code should properly handle filenames containing non-ASCII characters (Chinese, Japanese, Korean, etc.) without crashing.

Suggested Fix

Ensure all string slicing operations use character boundaries instead of raw byte indices. In Rust, this can be done by:

• Using .chars() iterator for character-based operations
• Using .char_indices() to get valid byte boundaries
• Using .is_char_boundary() to validate indices before slicing

Additional Context

This occurred during a documentation review operation (/docs command) on a project with Chinese documentation files.