[BUG] UTF-8 字符边界错误导致 CLI 崩溃 (Panic on Chinese character boundary)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug Description

Claude Code CLI crashes with a panic when processing responses containing Chinese characters. The error indicates incorrect UTF-8 string slicing at a character boundary.

Error Message

thread '<unnamed>' (6686071) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 5 is not a char boundary; it is inside '析' (bytes 3..6) of `分析。你需要为高管层提供简洁有力的洞察概览。\n\n## 分析框架\n\n### 1. Executive Summary（一句话结论`
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.0.73
• OS: macOS 26.1 (Build 25B78)
• Platform: darwin (Darwin 25.1.0)
• Locale: Chinese (中文) environment

Reproduction

The crash occurs when:

1. Working in a project with Chinese language instructions (CLAUDE.md contains Chinese)
2. Assistant generates responses with substantial Chinese text
3. CLI attempts to truncate or process the response string
4. String slicing occurs at an incorrect byte position within a multi-byte UTF-8 character ('析' = 3 bytes)

Expected Behavior

CLI should correctly handle UTF-8 character boundaries when:

• Truncating long responses
• Processing or displaying Chinese/multi-byte characters
• Any string slicing operations

Actual Behavior

CLI panics with "byte index is not a char boundary" error and aborts.

Impact

• CLI becomes unusable for projects with Chinese documentation
• Work sessions are interrupted and context is lost
• Affects users in Chinese-speaking regions or working with multilingual codebases

Suggested Fix

Ensure all string slicing operations use character-aware methods:

• Use .chars().take(n) instead of direct byte indexing
• Use str::char_indices() for safe boundary detection
• Validate slice positions with is_char_boundary() before slicing

Workarounds

Users can temporarily:

• Request shorter, more concise responses
• Break complex tasks into smaller subtasks
• Reduce Chinese character density in responses

What Should Happen?

Claude Code CLI should correctly handle UTF-8 character boundaries when processing, truncating, or displaying responses containing Chinese or other multi-byte Unicode characters. The CLI should remain stable regardless of the language used in responses.

Error Messages/Logs

thread '<unnamed>' (6686071) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
  byte index 5 is not a char boundary; it is inside '析' (bytes 3..6) of `分析。你需要为高管层提供简洁有力的洞察概览。\n\n## 分析框架\n\n### 1. Executive Summary（一句话结论`
  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

Steps to Reproduce

1. Create a project with Chinese language instructions in CLAUDE.md
2. Start a Claude Code session in this project
3. Ask Claude to perform tasks that generate responses with substantial Chinese text (e.g., data analysis explanations in Chinese)
4. Wait for Claude to generate a long response containing Chinese characters
5. CLI crashes when attempting to display/process the response

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.0.73

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Labels: bug, i18n, unicode, crash
• Additional context:

This affects users in Chinese-speaking regions or anyone working with multilingual codebases. The root cause is incorrect UTF-8 string slicing - the character '析' is a 3-byte UTF-8 sequence, and the code is trying to slice at byte index 5, which falls inside this character.