Claude Sonnet 5 corrupts Korean (Hangul) in Claude Code tool-call parameters - is there a workaround?
With Claude Code and Sonnet 5, Korean text in tool-call parameters such as AskUserQuestion and TodoWrite sometimes comes out as wrong but valid Hangul syllables. The reporter found the model writes these strings as \uXXXX escapes and mis-spells the hex codepoints. Is there a fix or workaround?
Originally asked on GitHub: https://github.com/anthropics/claude-code/issues/83033
4 answers
Status: open. A Claude Code maintainer said that on CLI 2.1.233 the CLI decodes escapes faithfully, so a mis-spelled codepoint shows up as a wrong syllable and the CLI cannot repair it. The issue was passed to the model team, and the team is looking at whether the harness should steer the model toward literal UTF-8 in tool parameters.
The workaround reported in the thread is to add this instruction to CLAUDE.md, memory, or the system prompt:
"Always write Korean (and other non-ASCII) strings in tool-call parameters as literal UTF-8; never as \uXXXX unicode escapes."
The reporter says this suppressed the corruption in their field use and in a controlled test. In that test, runs that used escapes were corrupted in every case (45 of 45), while literal-writing runs were clean.
The same problem was reported on Opus 5 and on MCP write tools such as Notion and Jira. In the MCP case a wrong syllable can still be valid Hangul and go unnoticed. One user built a PreToolUse hook that compares outgoing Korean text against a reference file, but the thread does not report how well it works.
To check whether the escapes appear on your version, capture raw output with claude -p --output-format stream-json --include-partial-messages and look for escape sequences in the partial_json deltas. Session JSONL stores already-decoded input, so escapes do not show there.
Did this work for you?What a GitHub user tried on GitHub (Worked)
Ran a controlled A/B test against Sonnet 5 via Bedrock ConverseStream with a forced Korean AskUserQuestion-style call. Runs that used escapes were corrupted 45 of 45 times, while literal-writing runs were clean. Instructing the model to write literal UTF-8 suppressed the corruption.
Source: https://github.com/anthropics/claude-code/issues/83033 (opens external site)
Did this work for you?What @bcherny tried on GitHub (Didn't work)
Ran claude -p --model sonnet with --output-format stream-json --include-partial-messages to build a Korean TodoWrite list on CLI 2.1.233, then inspected the raw partial_json deltas. All three runs were literal UTF-8 with no escapes and no substituted syllables, so the bug did not reproduce in these runs.
Source: https://github.com/anthropics/claude-code/issues/83033#issuecomment-5306359017 (opens external site)
Did this work for you?What @YourBestDeveloper tried on GitHub (Outcome unclear)
Built a PreToolUse hook (hangul-corruption-guard) that diffs outgoing Korean text against a reference file staged beforehand and blocks the write when they diverge, for MCP write tools.
Source: https://github.com/anthropics/claude-code/issues/83033#issuecomment-5598738956 (opens external site)
Did this work for you?