[BUG] Panic when processing Japanese text: byte index is not a char 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?

Claude Code crashes with a Rust panic when processing Japanese (multibyte) text. The error occurs during string slicing where a byte index falls inside a multibyte UTF-8 character.

Root Cause Analysis

The panic message indicates that the code is attempting to slice a string at byte index 2, but the Japanese character 'み' occupies bytes 0-3 (3 bytes in UTF-8). This suggests that somewhere in the codebase, string operations are using byte indices instead of character boundaries when handling multibyte characters.

Environment

• Claude Code version: 2.0.76
• OS: macOS 26.2 (Build 25C56)
• Terminal: xterm-256color
• Shell: zsh
• Locale: C.UTF-8

Steps to Reproduce

The crash occurs intermittently during normal usage with Japanese text. The specific trigger is unclear, but it appears to be related to:

• Status line rendering
• Text truncation for display
• Processing of configuration/profile text containing Japanese characters

Expected Behavior

Claude Code should properly handle UTF-8 multibyte characters by using character boundaries instead of raw byte indices when performing string operations.

Suggested Fix

In Rust, string slicing should use methods that respect character boundaries:

• Use .chars().take(n) instead of &s[..n] for truncation
• Use .char_indices() to find valid slice points
• Consider using the unicode-width crate for display width calculations

Additional Context

This issue affects users who use Claude Code with Japanese (and likely other CJK languages or any multibyte UTF-8 text) in their workflows, file names, or configurations.

What Should Happen?

Claude Code crashes with a Rust panic when processing Japanese (multibyte) text. The error occurs during string slicing where a byte index falls inside a multibyte UTF-8 character.

Error Messages/Logs

thread '' 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 み（デフォルト＆Onboardingプロファイル両方）
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

The panic message indicates that the code is attempting to slice a string at byte index 2, but the Japanese character 'み' occupies bytes 0-3 (3 bytes in UTF-8). This suggests that somewhere in the codebase, string operations are using byte indices instead of character boundaries when handling multibyte characters.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.0.76

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Expected Behavior

Claude Code should properly handle UTF-8 multibyte characters by using character boundaries instead of raw byte indices when performing string operations.

Suggested Fix

In Rust, string slicing should use methods that respect character boundaries:

• Use .chars().take(n) instead of &s[..n] for truncation
• Use .char_indices() to find valid slice points
• Consider using the unicode-width crate for display width calculations

Additional Context

This issue affects users who use Claude Code with Japanese (and likely other CJK languages or any multibyte UTF-8 text) in their workflows, file names, or configurations.