Panic when processing Korean (UTF-8 multibyte) characters in string slicing

Resolved 💬 3 comments Opened Dec 18, 2025 by seokmogu Closed Dec 21, 2025

Bug Description

Claude Code crashes with a Rust panic when processing strings containing Korean characters. The error occurs because the code attempts to slice a UTF-8 string at a byte index that falls in the middle of a multibyte character.

Error Message

thread '<unnamed>' (7643958) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 16 is not a char boundary; it is inside '색' (bytes 14..17) of `용 기업 검색 (하이브리드)')`
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 bypassPermissions

Root Cause

Korean characters (like '색') occupy 3 bytes in UTF-8 encoding (bytes 14-17 in this case). The code is attempting to slice the string at byte index 16, which is in the middle of the character '색', causing an invalid UTF-8 boundary error.

The problematic string appears to be: 용 기업 검색 (하이브리드)

Environment

  • Claude Code Version: 2.0.71
  • OS: macOS (Darwin 24.5.0)
  • Shell: zsh
  • Command: claude --permission-mode bypassPermissions

Expected Behavior

Claude Code should properly handle UTF-8 multibyte characters (Korean, Chinese, Japanese, emoji, etc.) by ensuring string operations respect character boundaries, not byte boundaries.

Suggested Fix

When slicing strings in Rust, use character-aware methods like:

  • str::char_indices() to find valid character boundaries
  • str::chars() with take() and skip() for character-based slicing
  • Crates like unicode-segmentation for grapheme cluster awareness

Additional Context

This bug likely affects all users working with non-ASCII text in their codebase or prompts.

View original on GitHub ↗

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