[MODEL] Sustained Korean-language sessions degrade into ill-formed Hangul or drift fully to English — recurring cross-model pattern, repeatedly auto-closed as stale

[MODEL] Sustained Korean-language sessions degrade into ill-formed Hangul or drift fully to English — recurring cross-model pattern, repeatedly auto-closed as stale without maintainer review

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports (see "Related Issues" below — this report explicitly builds on four of them)
• [x] This report does NOT contain sensitive information

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Ordinary Korean-language coding work in Claude Code, sustained continuously for roughly 30–60+ minutes (many turns / tool calls, growing context). No unusual prompt triggers it — it's a function of sustained session length/context size, not a specific instruction.

What Claude Actually Did

After working continuously for a while, one or both of the following happens in the same session:

1. Korean output stops being well-formed: syllables come out as incorrect vowel/consonant (jamo) combinations — valid-looking Hangul that isn't the intended word.
2. The response drifts fully into English mid-session, even though the user keeps writing in Korean and nothing in the conversation asked for a language change.

This matches the exact failure family already independently reported (and separately closed) in:

• #61142 (closed not_planned, auto-stale, 5 independent confirmations) — a single Korean word ("영역") replaces other content words throughout long responses/tables; reporter confirmed it reproduces on both claude-opus-4-7 and claude-opus-4-8 (not fixed by a model upgrade)
• #59618 (closed not_planned, auto-stale) — same collapse pattern, different placeholder token ("측"); confirmed regression window tied to a specific Claude Code version by a second independent reporter
• #63159 (closed as duplicate of #61142) — Korean grammar itself (particles, verb endings, agreement) breaks down in long sessions; English output in the same session at the same point stays fine, ruling out a generic context-limit explanation
• #32181 (closed not_planned, auto-stale) — text output gradually and irreversibly drifts from the user's language (Japanese in that report) to English as a session gets deeper into code-heavy work; the agent never self-detects the drift
• #53665 (closed) — Korean in AskUserQuestion tool_use JSON parameters comes out as syllable-level substitutions that are valid Unicode but the wrong word — explicitly not mojibake/encoding corruption, described there as a token-level decoding issue

Why this is not the same bug as the (already-fixed) CJK rendering/paste issues: Claude Code's changelog shows several terminal rendering CJK-garbling fixes have shipped (e.g. "Fixed Japanese/Korean/Chinese text rendering as garbled characters on Windows in no-flicker mode", "Fixed pasted Korean/CJK text turning into mojibake in terminals that deliver paste as per-byte extended-key events"). Those are display/paste decode-path bugs. This report is different: the corrupted or wrong-language text is what the model itself generates/emits, not a terminal decoding artifact — consistent with #63159's and #53665's explicit findings that this is a generation/decoding issue, not an encoding one.

Expected Behavior

Output language and Hangul well-formedness should stay stable regardless of how long the session has been running or how large the context has grown.

Files Affected

Not applicable — this is a text-output-only issue; no file corruption observed.

Permission Mode

Varies across sessions — not correlated with permission mode.

Can You Reproduce This?

Sometimes (intermittent) — appears correlated with sustained session length (roughly 30–60+ minutes of continuous work / accumulated context) rather than any specific prompt or action.

Steps to Reproduce

1. Start a Claude Code session and communicate primarily in Korean.
2. Do continuous coding work for 30–60+ minutes across many turns, letting context accumulate.
3. Observe Korean output beginning to contain ill-formed jamo/syllable combinations, or the assistant's prose switching wholesale to English despite the user continuing in Korean.

Claude Model

Sonnet (Sonnet 5 at time of this report) — the linked reports show this same behavior family on Opus 4.7 and Opus 4.8, so this is not limited to one model tier or version.

Relevant Conversation

I don't have a byte-exact saved capture of my own corrupted output from this report (noticed the pattern over repeated long sessions rather than screen-capturing it in the moment). For concrete verbatim examples of the same failure family, see the quoted excerpts in #61142, #59618, and #53665 (linked above), which show the corruption in detail. I can add a live capture here as a follow-up comment if/when I catch one directly.

Impact

Medium-High — breaks the human-agent communication channel for non-English (here, Korean) users specifically during the long, sustained agentic sessions Claude Code is designed to support. Underlying tool calls/file edits are reportedly unaffected in the linked reports — only the natural-language channel degrades — but that channel is how a non-English user tracks and directs the agent's work.

Claude Code Version

2.1.215 (Claude Code)

Platform

Anthropic API

Additional Context

• All five linked reports (#61142, #59618, #63159, #32181, #53665) were closed by the automated stale-issue bot with no maintainer (non-NONE-association) comment in any of the threads — none were closed because they were fixed or investigated by Anthropic. Given how consistently this same failure shape has been independently rediscovered by unrelated Korean/Japanese-speaking users across many Claude Code versions and at least three model generations, I'd ask that this be triaged as a genuine open model-behavior gap rather than auto-closed again as stale/duplicate.
• Environment for this report: Windows 11 (10.0.26200), VS Code integrated terminal, Windows PowerShell 5.1, console codepage already UTF-8 (65001), ko-KR culture — i.e. not a system-codepage misconfiguration, consistent with the linked reports' finding that this isn't an encoding/locale-setup issue.