claude-code - 💡(How to fix) Fix [MODEL] Japanese output corruption: model emits visually-similar but wrong kanji (Opus 4.7)

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Working in Japanese on Proxmox/Kubernetes homelab tasks. Claude generated AskUserQuestion prompts in Japanese to confirm operational steps (Zabbix maintenance mode, VM restart, pod noise handling).

Example user-side instructions in the session:

• "Zabbix で停止中の VM (mail/Bazzite/puter) のアラートをどう扱うか相談"
• "VM 100 (OMV) の guest-agent を有効化する手順を聞きたい"
• "cp1 再起動時に pod が鳴らすアラートをどう抑えるか相談"

What Claude Actually Did

Claude generated AskUserQuestion text in Japanese with kanji-level substitutions that produced non-words. Observed THREE separate corruption events within a single working session today (2026-05-16):

Case 1 — option label Expected: "ack で モグラ叩き" (whack-a-mole) Actual: "ack で モグラ鯰し" Corruption: 叩き → 鯰 (unrelated kanji substitution)

Case 2 — question text Context: VM restart via qm shutdown → qm set --agent 1 → qm start Expected: "VM 100 (OMV) を再起動経由で入れ替えてよいですか？" Actual: "VM 100 (OMV) を在控経由で入れ替えてよいですか？" Corruption: 再起動 → 在控 (3 chars compressed to 2 chars; both kanji wrong)

Case 3 — question text Context: pod noise handling on cp1 reboot Expected: "cp1 再起動時に鳴るノイズをどうしますか？" Actual: "cp1 再起動時に鳥るノイズをどうしますか？" Corruption: 鳴 → 鳥 (radical dropped: 鳴 = 口 + 鳥; the 口 component was omitted) Notably: the same word "鳴る" appeared CORRECTLY in the immediately preceding sentence of the same response ("必ず鳴る"), then got corrupted in the next sentence.

Expected Behavior

Claude should output grammatically and lexically correct Japanese kanji. The corrupted forms (鯰し / 在控 / 鳥る) are not valid Japanese words.

Files Affected

None. This is an output-quality issue; no files were touched.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not deterministically reproducible. Three occurrences happened naturally during normal Japanese-language conversation about infrastructure tasks within one ~2-hour session. All three were inside AskUserQuestion tool calls (option labels or question text), but the sample is too small to confirm correlation with that tool specifically.

Conditions during observation:

• Japanese-only working language with mixed technical English terms (qm, VMID, pod, etc.)
• Long conversation (1M-context Opus)
• AskUserQuestion was being called frequently to confirm operational steps

Claude Model

Opus

Relevant Conversation

**Case 1** — AskUserQuestion option label

> ack で モグラ鯰し (Recommended)
> event.acknowledge で 「意図的に停止中」とコメント付けて close する...

(Should be: モグラ叩き — whack-a-mole idiom)

---

**Case 2** — AskUserQuestion question text

> VM 100 (OMV) を在控経由 (qm shutdown → qm set --agent 1 → qm start) で入れ替えてよいですか？ ダウンタイム 1〜2分程度

(Should be: 再起動経由 — "via restart")

---

**Case 3** — AskUserQuestion question text, with correct form in same response

> 朝の事象でも今回でも、これらの pod は「cp1 再起動のたびに必ず鳴る」性質。3 つの方針があります:
> [AskUserQuestion]
> cp1 再起動時に鳥るノイズをどうしますか？

(Note: 鳴る rendered correctly in the explanatory sentence, then corrupted to 鳥る in the question itself within the same response.)

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.143 (Claude Code)

Platform

Anthropic API

Additional Context

Environment details

• Claude Code: VSCode native extension (not CLI)
• Exact model: claude-opus-4-7 (1M context window)
• OS: Ubuntu Linux, kernel 6.8
• Anthropic status page: "All Systems Operational" throughout observation period
• Most recent related incident on status page: "Elevated errors on Claude Opus 4.7" (2026-05-14, resolved). 2026-05-15 also had an Opus 4.6/Sonnet 4.6 incident but Opus 4.7 was noted as having "returned to normal."

Corruption pattern analysis

Three distinct failure modes observed in a single session:

1. Unrelated substitution — Case 1 (叩き → 鯰). No obvious visual, phonetic, or semantic relationship between source and target kanji.
2. Multi-character compression — Case 2 (再起動 → 在控). Three characters collapsed to two; both substituted kanji are wrong.
3. Radical/component dropping — Case 3 (鳴 → 鳥). The 鳴 character decomposes structurally as 口 + 鳥; the model emitted only the right-hand component.

In all cases:

• UTF-8 byte sequences are valid (rules out transport/encoding corruption)
• The output is a non-word in Japanese (not just an unusual word choice)
• Case 3 is particularly diagnostic: the same word was rendered correctly elsewhere in the same response

Frequency

Three occurrences in one session feels above the historical baseline for me, suggesting a possible recent regression in Japanese kanji generation for Opus 4.7. I cannot rule out coincidence, but flagging for investigation.

Workarounds attempted

• None yet. About to try /model switch to Sonnet 4.6 to see if Sonnet exhibits the same corruption pattern, which would indicate a broader issue vs. an Opus-4.7-specific regression.