[BUG] Rust panic on Korean (UTF-8) character boundary when editing markdown

Resolved 💬 3 comments Opened Jan 4, 2026 by Kyoungsoo2314 Closed Jan 8, 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?

Claude Code crashes with a Rust panic when editing Korean markdown files. The panic occurs during text processing when the code attempts to slice a string at an invalid byte boundary inside a Korean character.

The error occurs during normal editing operations on markdown files containing Korean text. The application terminates unexpectedly without saving changes.

What Should Happen?

Claude Code should correctly handle Korean (and other multibyte UTF-8) characters without crashing. String operations should respect UTF-8 character boundaries when processing non-ASCII text.

Error Messages/Logs

thread '<unnamed>' (80064) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb\library\core\src\str\mod.rs:833:21:
  byte index 12 is not a char boundary; it is inside '다' (bytes 10..13) of ` 시작했다.`
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps to Reproduce

  1. Open Claude Code on Windows
  2. Work with a markdown file containing Korean text (e.g., sentences ending with "시작했다.")
  3. Ask Claude to edit/refine the Korean text content
  4. Claude Code attempts to update text containing Korean characters
  5. Rust panic occurs during string slicing operation

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Claude Code v2.0.76

Claude Code Version

Claude Code v2.0.76

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This appears to be a byte-level string slicing issue where the Rust code doesn't respect UTF-8 character boundaries for multibyte characters.

Korean characters use 3 bytes in UTF-8 encoding:

  • '다' occupies bytes 10-13 in the string 시작했다.
  • The code attempted to slice at byte index 12, which is in the middle of the character

This bug likely affects all CJK (Chinese, Japanese, Korean) text and other non-ASCII Unicode characters.

Installation type: Native (Windows binary)
Installation path: C:\Users\<user>\.local\bin\claude.exe

View original on GitHub ↗

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