[BUG] Panic when processing Korean (UTF-8 multibyte) strings

Resolved 💬 3 comments Opened Dec 29, 2025 by evan-labs Closed Jan 1, 2026

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?

Description

Claude Code CLI crashes with a Rust panic when processing Korean text. The error indicates an incorrect byte index calculation that falls in the middle of a UTF-8 multibyte character.

Error Message

thread '<unnamed>' (97758856) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
byte index 23 is not a char boundary; it is inside '다' (bytes 21..24) of 제출해주셨습니다. 감사합니다!
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5, aborting
[1] 55663 abort claude --permission-mode "bypassPermissions"

Environment

  • Claude Code Version: 2.0.76
  • OS: macOS (Darwin 24.3.0)
  • Platform: darwin

Root Cause Analysis

The panic occurs because the code attempts to slice a UTF-8 string at byte index 23, which falls inside the Korean character '다' (occupying bytes 21-24). Korean characters require 3 bytes in UTF-8 encoding, and the string slicing logic doesn't account for character boundaries.

The problematic string appears to be: 제출해주셨습니다. 감사합니다! (Korean for "Submitted. Thank you!")

Suggested Fix

Replace byte-based string slicing with character-aware methods:

// Instead of:
&string[0..23] // Can panic on multibyte characters

// Use:
string.chars().take(n).collect::<String>()
// Or use char_indices() to find valid boundaries

Steps to Reproduce

  1. Run Claude Code CLI with Korean language input
  2. Trigger feedback submission or similar functionality that processes the string 제출해주셨습니다. 감사합니다!

Impact

  • CLI terminates abruptly with abort signal
  • Affects users with Korean (and likely other multibyte UTF-8) locales

What Should Happen?

Claude Code CLI crashes with a Rust panic when processing Korean text. The error indicates an incorrect byte index calculation that falls in the middle of a UTF-8 multibyte character.

Error Messages/Logs

thread '<unnamed>' (97758856) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/core/src/str/mod.rs:833:21:
  byte index 23 is not a char boundary; it is inside '다' (bytes 21..24) of `제출해주셨습니다. 감사합니다!`
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  fatal runtime error: failed to initiate panic, error 5, aborting
  [1]    55663 abort      claude --permission-mode "bypassPermissions"

Environment

  - Claude Code Version: 2.0.76
  - OS: macOS (Darwin 24.3.0)
  - Platform: darwin

  Root Cause Analysis

  The panic occurs because the code attempts to slice a UTF-8 string at byte index 23, which falls inside the Korean character '다' (occupying bytes 21-24). Korean characters require 3 bytes in UTF-8 encoding, and the string slicing logic doesn't account for character boundaries.

  The problematic string appears to be: 제출해주셨습니다. 감사합니다! (Korean for "Submitted. Thank you!")

  Suggested Fix

  Replace byte-based string slicing with character-aware methods:

  // Instead of:
  &string[0..23]  // Can panic on multibyte characters

  // Use:
  string.chars().take(n).collect::<String>()
  // Or use char_indices() to find valid boundaries

Steps to Reproduce

Steps to Reproduce

  1. Run Claude Code CLI with Korean language input
  2. Trigger feedback submission or similar functionality that processes the string 제출해주셨습니다. 감사합니다!

Impact

  • CLI terminates abruptly with abort signal
  • Affects users with Korean (and likely other multibyte UTF-8) locales

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

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