claude-code - 💡(How to fix) Fix AskUserQuestion / tool calls render Japanese (non-ASCII) as raw \uXXXX Unicode escape sequences [1 participants]

Environment

• Claude Code: 2.1.126
• OS: macOS 26.2 (Build 25C56)
• Terminal: Ghostty
• Model: Opus 4.7 (1M context, claude-opus-4-7[1m])

Summary

When Claude invokes the AskUserQuestion tool (and likely other tools) with Japanese/non-ASCII text in question / header / option.label / option.description, the model's tool input JSON arrives at the TUI with Unicode characters serialized as \uXXXX escape sequences. The TUI surfaces those raw escape literals to the user instead of rendering decoded UTF-8.

Reproduction (observed in a working session, not a synthetic minimal repro)

The model issued AskUserQuestion calls during a Japanese-language session. When Ryo (the user) inspected the rendered question chip / option labels, they saw text like:

Codex 起動しますか?

instead of the intended:

Codex 起動しますか?

This happened across multiple AUQ invocations in the same session — every Japanese string in question, header, option.label, and option.description came through with raw \u escapes.

Expected behavior

Tool input string fields should be decoded back to UTF-8 before being shown in the TUI. JSON strings are equivalent whether the model emits "コデックス" or "コデックス" — the TUI should treat them identically when rendering to the terminal.

Actual behavior

Raw \uXXXX literal sequences are shown to the user. This makes Japanese AUQ chips and option lists effectively unreadable.

Suspected root cause

Two layers may contribute:

1. Model side: Claude (Opus 4.7 in this case) sometimes emits tool input JSON with non-ASCII characters escaped as \uXXXX. This is RFC 8259-compliant but probably an RLHF training artifact (the model generalizes from JSON examples that escape non-ASCII). It is documented in some style guides that LLMs do this for English-trained reasons.
2. TUI side: The renderer for AskUserQuestion question text / option labels appears to pass the raw JSON-decoded string through without re-decoding \u sequences. If the JSON parser used for the tool call upstream is producing the literal 起 6-character sequence (instead of the single character U+8D77), the TUI shows it verbatim.

It looks more like the TUI render path issue: a properly-parsed JSON string would already contain 起 (U+8D77) regardless of whether the source said 起 or 起. So somewhere upstream the JSON is being treated as plain text or the escapes survive into the displayed string. Worth verifying with a captured tool call payload.

Workaround

The user-facing impact can be reduced if Claude is instructed to emit raw UTF-8 in tool inputs (no \u escapes). Anthropic's CLAUDE.md guidance for users in CJK locales is already moving in this direction (Unicode escape (\\uXXXX) を手打ちで生成しない — UTF-8 直接で渡す). But the fix should also live on the TUI side so non-instructed sessions are not broken for Japanese / Chinese / Korean / Arabic / etc users.

Impact

• AskUserQuestion is unusable for Japanese-only sessions (cannot read the question chips or options without manual decoding).
• Likely affects other tools that surface tool inputs in the TUI (slash command args, tool argument summaries, etc.).
• Not a code-correctness issue (the underlying JSON is valid), but a UX issue affecting all CJK users.

Suggested fix priorities

1. (TUI) Always pass tool input string fields through a JSON-aware decode before rendering.
2. (Model) Tighten RLHF guidance / system prompt to prefer raw UTF-8 in tool input JSON.
3. (Docs) Note this as a known issue if a fix is pending.

Happy to provide a captured AskUserQuestion payload (with the raw \uXXXX literals visible) if that helps reproduce on your side.