[BUG] Panic when processing UTF-8 characters - byte boundary error

Resolved 💬 4 comments Opened Dec 17, 2025 by kk121a Closed Dec 21, 2025

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 CLI crashes with a Rust panic when processing text containing UTF-8 (CJK) characters. The error occurs due to incorrect string slicing at a non-character boundary in UTF-8 encoded text.

The application attempts to slice a string at a byte index that falls in the middle of a multi-byte UTF-8 character, causing an immediate abort.

What Should Happen?

Claude Code should properly handle UTF-8 multi-byte characters (Chinese/Japanese/Korean/emoji etc.) and slice strings only at valid character boundaries. The application should not crash when processing non-ASCII text.

Error Messages/Logs

thread '<unnamed>' panicked at /rustc/library/core/src/str/mod.rs:833:21:
  byte index 44 is not a char boundary; it is inside 'X' (bytes 42..45) of `[CJK text...]`
  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 markdown file containing UTF-8 text (e.g., test.md)
  2. Open Claude Code CLI in the directory
  3. Have a conversation that involves reading or processing the UTF-8 text file
  4. The crash occurs during text processing (possibly during conversation history display, summarization, or tool output truncation)

Note: The crash appears to happen when the internal string truncation logic hits a multi-byte character boundary.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.71

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root Cause Analysis:
The Rust code attempts to slice a UTF-8 string at byte index 44, which falls in the middle of a 3-byte UTF8 character 'UTF-8' (bytes 42-45). In UTF-8, Chinese characters occupy 3 bytes, and slicing must occur at valid character boundaries.

Suggested Fix:
Use character-aware string slicing methods in Rust:

```rust
// Use floor_char_boundary (Rust 1.73+):
&text[..text.floor_char_boundary(max_len)]

// Or use char_indices:
text.char_indices()
.take_while(|(i, _)| *i < max_len)
.last()
.map(|(i, c)| &text[..i + c.len_utf8()])

This issue affects all users working with CJK (Chinese, Japanese, Korean) text or other multi-byte UTF-8 characters.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗