Panic: UTF-8 string slicing error when processing files with multi-byte characters (β, Korean, etc.)

Resolved 💬 3 comments Opened Jan 8, 2026 by love2wisdom Closed Jan 12, 2026

Bug Description

Claude Code CLI crashes with a Rust panic when processing files containing multi-byte UTF-8 characters like Greek letters (β) or Korean text.

Error Message

thread '<unnamed>' (70320) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb\library\core\src\str\mod.rs:833:21:
byte index 2 is not a char boundary; it is inside 'β' (bytes 1..3) of (β = 
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Root Cause Analysis

The error occurs because:

  1. The Greek letter β is a 2-byte character in UTF-8 (occupies bytes 1..3 in the string)
  2. The Rust code attempts to slice the string at byte index 2
  3. Byte index 2 falls inside the multi-byte character β, not at a character boundary
  4. Rust panics because UTF-8 strings can only be sliced at valid character boundaries

Context

  • Was reading/processing a Python script file containing statistical notation like (β = 0.111, ...)
  • The file also contained Korean text
  • The crash happened during normal CLI operation (reading file contents or displaying output)

Environment

  • OS: Windows 10/11 (MSYS_NT-10.0-26200)
  • Claude Code Version: Latest (as of 2025-01-09)
  • Platform: win32

Steps to Reproduce

  1. Create or open a file containing multi-byte UTF-8 characters like β (Greek beta)
  2. Have Claude Code read or process the file
  3. CLI crashes with the above panic message

Suggested Fix

The string slicing code should use character boundaries instead of byte indices. In Rust, this can be done by:

  • Using .chars() iterator with .take() and .collect()
  • Using .char_indices() to find valid slice points
  • Using crates like unicode-segmentation for proper grapheme handling

Workaround

Replace multi-byte characters with ASCII equivalents (e.g., βB) before processing.

View original on GitHub ↗

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