[BUG] Sonnet 5 writes Korean tool-call parameters as \uXXXX escapes and mis-spells the hex, corrupting Hangul (100% corruption when escape-writing engages; likely root cause of #80009 / #78996)

Field report: same failure mode at far higher density (non-engineer user, AskUserQuestion)

Another instance from our company, this time from an ops colleague's interactive session (Sonnet), not a controlled run. Same surface as the linked reports — an AskUserQuestion prompt — but the corruption density is well past the ~3–5% in the root-cause section above: nearly every content word is a wrong syllable, so the question and its options aren't merely misspelled, they're unreadable. A native Korean speaker cannot reconstruct what is being asked.

<img width="621" height="303" alt="Image" src="https://github.com/user-attachments/assets/fe72366c-e175-4ca7-a693-d445641e9aeb" />

What survives intact is what you'd expect if the model were hand-spelling hex for Hangul only:

• ASCII and digits are clean: Other, Submit answers, 9시·13시·16시, 9/13/16시
• Function words and a few common syllables survive — the question line reads 뽁일 기벘이뛌 어느 시점에 확인할까요?, where only the tail 어느 시점에 확인할까요? is well-formed
• Content nouns are almost entirely substituted, and a large share land on syllables outside KS X 1001 (뛌, 뾯, 뾩, 뽁, 첤 — as read off the screenshot), matching the fingerprint described above

Two things this case adds:

1. Severity isn't bounded by the 3–5% density. AskUserQuestion is a blocking UI: the turn cannot proceed until the user selects an option, and here there is nothing legible to select. The only recourse is to abandon the turn.
2. This is the default experience for non-engineer users. No CLAUDE.md workaround was in place. Ops users are the least equipped to recognize "the model mis-spelled a unicode escape" and the most likely to conclude the tool is broken — which, for this turn, it effectively is.

Evidence grade: screenshot only. The session ran on a colleague's machine and the JSONL wasn't retained, so I can't produce raw pre-decode deltas for this run. Reporting it as a severity data point, not as additional root-cause evidence.

I also saw the problem frequently.

As far as I know, this is a very important issue for East Asian language users.

Thanks for the unusually thorough writeup — the raw-delta capture and A/B numbers are exactly what's needed here.

What we tried on the released CLI 2.1.233 (macOS): three non-interactive runs (claude -p --model sonnet --output-format stream-json --include-partial-messages) asking Sonnet 5 to build a 6–8 item Korean TodoWrite list, then inspecting the raw partial_json deltas. All three runs came back as literal UTF-8 with zero \uXXXX escapes and no substituted syllables. That's consistent with your finding that the escape-writing is intermittent rather than a CLI-side transform.

On the client side, Claude Code decodes whatever escapes the model emits faithfully, so a mis-spelled hex codepoint necessarily lands as a wrong Hangul syllable — the CLI can't repair that. Your evidence that this reproduces against the Bedrock API with no CLI in the loop points at model output behavior; we've passed this issue (and #80009 / #78996) to the model team, and we're also looking at whether the harness should steer the model toward literal UTF-8 in tool parameters, which you report fully suppresses the class. Until then, the CLAUDE.md instruction in your workaround is the right mitigation.

If anyone hits this again, a --output-format stream-json --include-partial-messages capture showing the escapes in partial_json on the current version would help confirm it's still occurring.

🤖 Generated with Claude Code

Additional reproduction data point — also occurs on Opus 5, Claude Code CLI, 2026-08-19.

An AskUserQuestion call whose arguments were emitted as \uXXXX escapes corrupted one syllable:

• Intended: 멀쩡하게 (… U+BA40 U+C9F5 U+D558 U+AC8C …)
• Emitted escapes: 멀잩하게 → rendered as 멀잩하게 ('쩡' U+C9F5 → '잩' U+C7A9)

The corruption is present in the serialized tool_use input itself (session-log level), consistent with this issue's mis-spelled-hex root cause — not terminal rendering. Common syllables in the same payload (불러올·밝혔·뿔) survived; the rarer syllable broke.

Separately, a user of ours reported the U+FFFD variant back in July: "회의 후 불러올 사람이 누구인가요?" displayed with '불' (U+BD88) replaced, and the serialized JSON contained a literal � — i.e. the character was lost at argument-generation time. That observation also fits escape-miswriting rather than UTF-8 byte-boundary truncation.

Working mitigation for us: instructing the model (via skill/system prompt) to write Korean tool arguments as raw UTF-8 instead of \uXXXX escapes.

Same failure mode on a surface not mentioned above — MCP write tools (Notion notion-update-page,
Jira editJiraIssue). Caught live today:

잡히지  →  잡힐지
  '히' U+D788   choseong 18, jungseong 20, jongseong 0
  '힐' U+D790   choseong 18, jungseong 20, jongseong 8

Only the final consonant flips, so the result is still a well-formed Hangul syllable — the write
succeeds, no error, and it reads as a typo afterwards.

I put together a Claude Code plugin as a stopgap:
hangul-corruption-guard — a
PreToolUse hook that diffs outgoing Korean against a reference file staged beforehand and blocks
the write when they diverge. Since the corrupted output is a valid syllable, having something to
compare against is the only way to see it.

A mitigation, not a fix — posting in case it is useful to anyone else hitting this.