[BUG] Replies drift into English right after reading English tool output, despite a CLAUDE.md rule requiring Japanese; corrections do not hold

It happened again in the same session, after this issue was filed.

The model had just filed this report on the user's instruction and answered in Japanese for a few turns. Then two things triggered English again. One was a turn whose tool output was English (a git commit, and an English HANDOFF edit in a Python heredoc). The other was the user writing a short Japanese message ("ローカルサーバーをFunnel経由で検証します。先にコンパクトします。"). The model's reply to that message was entirely English.

The user then asked (translated): "Do you understand why you should file a bug report again?"

So filing the report and the in-session correction did not change the behaviour. The drift seems to follow the language of the most recent tool output, even when that output is only a commit message or a code edit, and even though the user's own message was in Japanese.

Recurred again in the same session (2026-09-23, after compaction). CLAUDE.md requires Japanese for every reply to the owner; the output style also says "Always respond in Japanese". The model's final reports for two consecutive turns (after a long tool-heavy stretch of work, with Japanese tool descriptions and Japanese progress lines just before) were written in English. The owner had to point it out again with a one-word message ("jap"). Pattern: drift happens in the final summary after many tool calls, even when interim one-line status messages were in Japanese.

Recurred twice more in the same session (2026-09-23). After the model had just apologised in Japanese and promised Japanese, its next two short replies (explaining a blocked permission and correcting a mistyped URL) were in English. The owner had to write "日本語で" again. Pattern now also seen on short replies right after a denied tool call, not only on long end-of-task summaries.

Added your case to the list of CLAUDE.md non-compliance https://github.com/anthropics/claude-code/issues/13689, consider upvoting it for visibility.

Reproduced the same issue. Sharing observations that may help narrow down the cause.

Environment: Linux (WSL2), Opus 5.5 (1M context), Concise output style, Japanese required by both CLAUDE.md and the language setting.

1. The CLI version made a difference

| Claude Code | Model | Replies that came back in English |
|---|---|---|
| 2.1.280 (several sessions on 2026-09-23) | Opus 5.5 | 0-7% (3 of 141 in one session) |
| 2.1.281 (2026-09-24) | Opus 5.5 | 14 of 31 (45%) |

The model has been Opus 5.5 since 09-23 and did not change. The regression started on the day we updated to 2.1.281. (This may help with the version-vs-model question left open in #96601.)

2. Switching the output style within the same session

| Segment | Japanese | English |
|---|---:|---:|
| Concise | 17 | 14 |
| Default | 4 | 0 |
| Concise (switched back) | 6 | 1 |
| Default (second time) | 4 | 0 |

English only appeared in the Concise segments. The counts are small.

3. Subagents did not drift, even under Concise

We gave the same English-reading task (summarize three English issues) to a named subagent and to a fork, under both Default and Concise. In all four runs, every reply and every thinking block was in Japanese.

4. The difference we could see

In the main session, every tool result and every user message ends with the English reminder "Concise output style is active. Be concise: lead with the result, skip preamble and narration, keep only what the user needs." That is roughly 90 times per session.
The fork inherits the Concise system prompt, yet its transcript contains this reminder zero times. The main session under Default does not get it either.

Every reply that came back in English started right after this reminder. It also happened when no English tool output had just been read (a reply to a Japanese user message).
Our working hypothesis: the trigger is not the Concise style itself, but the English reminder appended at the end of every turn. It would help if you could check whether the way this reminder is injected changed in 2.1.281.

Workaround: switching the output style to Default removes the reminder, and in our environment the drift to English stopped.

Correction to my previous comment.

After switching the output style to Default, the same session still produced a reply in English. Right before it, the model had read a shell script containing about 60 lines of English comments. In the Default segment, the English reminder ("Concise output style is active...") is not appended.

So I am weakening the hypothesis in my previous comment. The Concise reminder may be one trigger, but it is not the only one. Long English text read right before a reply (whether tool output or the Concise reminder) seems to override the language instruction. The zero English replies in the Default segments were likely because no long English text was read in those segments.

The workaround in my previous comment (switching to Default) is not a reliable fix. It may reduce how often this happens, but it does not stop it.

Same behaviour in the Claude desktop app (macOS), model claude-opus-5-5, Japanese required
by both ~/.claude/CLAUDE.md and "language": "japanese" in settings.json, plus a
UserPromptSubmit hook injecting the rule on every turn.

Counting one long session's transcript (replies with prose only):

• CLI 2.1.280: 5 of 119 replies in English (4%)
• CLI 2.1.281 (from 2026-09-24 20:46 UTC): 11 of 98 replies in English (11%)

Every English reply came right after reading English tool output or an English
message from another session. The injected per-turn rule did not prevent it.

Same on Hebrew (Linux, Claude Code CLI). Hebrew is required by both the project CLAUDE.md and the language setting.

I counted the final reply of each turn (code stripped, ≥30 letters) across 278 local transcripts of one project, only in sessions where the user wrote in Hebrew:

| Model | CLI | Final replies | In English |
|---|---|---|---|
| claude-opus-5 | 2.1.246–2.1.273 | 174 | 2 (1.1%) |
| claude-opus-5-5 | 2.1.280 | 164 | 14 (8.5%) |
| claude-opus-5-5 | 2.1.281 | 6 | 0 |
| claude-opus-5-5 | 2.1.282 | 22 | 7 (31.8%) |

About a 10× jump on switching to Opus 5.5, and 2.1.282 does not fix it (small sample). The trigger looks the same as in the other reports: a lot of English text read just before the reply (tool output, subagent reports, a long English CLAUDE.md and skill instructions).

Same pattern here with Italian instead of Japanese: Opus 5.5 on macOS, Claude Code 2.1.282, Concise output style. The English shows up mostly in the one-line status notes between tool calls and after subagent reports, and a correction holds for the next sentence at most.

On my last 30 days of transcripts it's 0.3% English on claude-opus-5 and 15.3% on claude-opus-5-5. Opus 5 on 2.1.281 had 0 out of 82, while Opus 5.5 drifted on 2.1.280, 2.1.281 and 2.1.282, so for me it tracks the model more than the CLI version. Full breakdown in #96601.

Same on Korean: Claude desktop app (Code tab, macOS), CLI 2.1.280–2.1.286. Korean is required in three places: "language": "ko", a custom output style written in Korean, and ~/.claude/CLAUDE.md.

I counted assistant text blocks in turns where I wrote in Korean. Main thread and interactive sessions only, code and paths stripped, ≥30 letters. A block counts as English when Hangul is under 15% of its letters.

| Model | Period | All text blocks | Final reply of turn |
|---|---|---|---|
| claude-opus-5 | 09-11 – 09-22 | 171 / 4,182 (4.1%) | 28 / 1,614 (1.7%) |
| claude-opus-5-5 | 09-23 – 10-04 | 204 / 1,657 (12.3%) | 8 / 528 (1.5%) |

On Opus 5.5 the English is mostly short progress notes between tool calls: 13.1% (194/1,484) when the previous item was a tool result, against 5.6% (10/178) right after my own message. Still happening on 2.1.286 today.

Same on Traditional Chinese (zh-TW): Claude Code CLI 2.1.286 on Windows 11. Chinese is required by the project CLAUDE.md and by a custom output style written in Chinese.

The clean part of our data is the model comparison: the same project, the same instructions and the same kind of work ran on several models over the last three weeks. I counted assistant text blocks in the transcripts (code blocks, inline code, URLs and file paths stripped; a block counts as English when it has at least 80 Latin letters and CJK characters are under a third of them; synthetic messages such as usage-limit notices excluded):

| Model | Text blocks | English |
|---|---:|---:|
| claude-fable-5 | 4,489 | 0 |
| claude-fable-5-1 | 434 | 0 |
| claude-opus-5 | 1,152 | 0 |
| claude-opus-4-6 | 267 | 2 (0.7%) |
| claude-sonnet-5-5 | 50 | 1 |
| claude-opus-5-5 | 3,607 | 147 (4.1%) |

By day there were zero English blocks before we switched to Opus 5.5 (2026-09-24). Today it peaked at 9.0% (40 of 445). Same shape as the other reports: mostly the one-line progress notes between tool calls, right after reading long English tool output (code, test runs, subagent and reviewer reports), and right after system-inserted turns such as task notifications.

A per-prompt UserPromptSubmit reminder did not stop it in our session either; the model slipped again in the very next reply. We have now added a PostToolUse hook that injects a one-line reminder only when the tool output is mostly English, since that is where the drift happens. Too early to report numbers.

Same on Korean, Claude Code CLI 2.1.292 on macOS, claude-opus-5-5[1m].
Korean is required on the first line of ~/.claude/CLAUDE.md ("all output, including one-line progress notes, in Korean; no English sentences") and in auto-memory.

One long tool-heavy session (Xcode/simctl builds, GitHub API, Athena/CloudWatch queries, Linear), counted the same way as the Korean comment above (code, inline code, URLs and paths stripped, ≥30 letters, English = Hangul under 15%):

| Previous item | English text blocks |
|---|---|
| tool result | 54 / 107 (50.5%) |
| user message | 5 / 19 (26.3%) |
| total | 59 / 126 (46.8%) |

The user corrected it four times ("영어쓰지마"). Each time the model apologized in Korean and promised Korean only, then the next progress line after a tool call was English again. It also slipped right after the session resumed from a compaction summary and after task notifications.

Supporting data for the tool-output trigger, from a Korean-language setup (1,840 turns of transcripts, method in #99704).

Opus 5.5 ended 9.4% of turns in English, against 0.6% for Opus 5 and Fable 5.1 under the same configuration. The rate was 10.8% after a skill with English text had been loaded and 5.4% before, and 11% in turns with more than ten tool calls against 7% with one to ten. The drift usually appears first in the status lines between tool calls. Context length and compaction showed no relationship, which fits the reading that recent English tool output, not the distance to the instruction, pulls the language.

Full breakdown: https://github.com/anthropics/claude-code/issues/99704

Same behaviour with German, so this is not specific to Japanese or Hebrew. My own report (#99603) was flagged as a duplicate of this one.

Environment: Claude desktop app (Code tab), Windows 11, Opus 5.5 and Sonnet 5.5. All user messages are in German. My global CLAUDE.md is written in German but has no explicit language rule, so this happens even without a "reply in language X" instruction.

Observed

• Replies switch to English mid-session while the user keeps writing German.
• After the switch, the session keeps answering in English instead of returning to German.
• It shows up in long, tool-heavy sessions, which fits the pattern above of drift after English tool output.

I have not measured reply counts or compared CLI versions, so I can't confirm the 2.1.281 regression from my side.