VSCode extension: AskUserQuestion popup corrupts Korean (Hangul) text

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 24, 2026

Environment

  • Claude Code running as a VSCode native extension
  • OS: macOS (Darwin 25.2.0)
  • Shell locale: LANG=C.UTF-8 (verified correct, not a terminal/locale issue)

Summary

When the AskUserQuestion tool shows its confirmation popup with Korean (Hangul) text, some of the displayed characters are corrupted. This isn't generic mojibake (e.g. replacement characters) — instead, whole syllables get swapped into different, valid-looking Hangul syllables, which suggests the text is being truncated/processed at a byte boundary instead of a UTF-8 character boundary somewhere in the popup rendering or answer-echoing pipeline. Korean UTF-8 syllables are 3 bytes each, so a byte-level cut mid-character followed by recombination with adjacent bytes would produce exactly this kind of scrambled-but-plausible-looking output.

Reproduction example

A question label meaning "Please select the deploy branch" (배포 브랜치를 선택해주세요) was shown/echoed back as:

배포 버리 묵을 선택해주세요.

("브랜치를" → "버리 묵을")

Another question meaning "Please select the app version" (앱 버전을 선택해주세요) was echoed as:

압 버전을 선택해주세요.

("앱" → "압")

And an option description ending in something like "...일치함" (matches) was echoed as:

...일쉱

The corruption appeared first in the popup itself (not just in the later "Your questions have been answered" summary text), and the same corrupted text then propagated into that summary echo — suggesting a single root cause in how the popup component handles/renders the Korean string.

Notes

  • This appears to be purely a display/rendering issue in the popup UI layer. The underlying structured answer values (e.g. which option was selected) were still received correctly by the agent despite the label text being visually corrupted.
  • Verified this is not a shell/terminal locale problem: LANG=C.UTF-8, and python3 -c "import sys; print(sys.getdefaultencoding(), sys.stdout.encoding)" reports utf-8 utf-8.

Suggested area to look at

Whatever code path truncates/measures/wraps question or option label strings for display width in the AskUserQuestion popup component — if it operates on raw bytes (or UTF-16 code units without surrogate/grapheme awareness) rather than Unicode grapheme clusters, it would produce this exact symptom for multi-byte scripts like Korean, Japanese, or Chinese.

View original on GitHub ↗