Claude Keeps Replying in English? 4 Patterns and How to Fix Each

If you use Claude in any language other than English, you have probably seen this: you write in Spanish, and the answer comes back in English. And once it happens, it tends not to switch back on its own.

It is not your imagination. The official Claude Code repository keeps receiving the same report, from people working in Spanish, Japanese and Traditional Chinese, and research has found that when the request and the answer are in different languages, even the strongest models fail to answer consistently in the language they were asked for. The important part is that there is more than one cause. How it happens splits into four patterns, and each one responds to a different fix.

Since late September 2026 in particular, after Opus 5.5 became Claude Code's default model, reports that the short messages Claude drops in the middle of a task come out in English have jumped. Some say it happened even with the language setting in place. In the author's own logs, too, the share of these short messages written in English rose from about 11% to about 50% (§2).

This article first helps you work out which pattern you are hitting, then shows how to fix each one. At the end, it sorts out a problem that started being reported in September 2026, long sessions where the output itself breaks down, keeping what has been confirmed separate from what has not.

1. Tell them apart first: four ways replies slip into English

The result looks the same every time, English where you expected your own language, but the pattern depends on when it switched and what came just before. Think back to what you were doing right before it happened.

Patterns 1 and 2 affect almost everyone, and one and the same setting prevents most of both. Pattern 3 has been reported only a few times so far, too few to generalize from: the cases on record involve East Asian languages such as Chinese, Japanese, and Korean, and there is no clear fix for it yet. Pattern 4 is a new one that surged from late September 2026; if English suddenly started showing up more for you around then, suspect Pattern 4 first. We start with it.

2. Since late September 2026, Pattern 4: short messages mid-task come out in English

This is an ongoing story with no official answer as of October 4, 2026. Verified facts, user reports, and the author's own measurements are kept separate below.

It started with a change of default model

According to Claude Code's official changelog, version 2.1.280 on September 22 made Opus 5.5 the default Opus model. Starting the next day, reports of replies reverting to English began arriving one after another in the official repository.

Source: the individual reports in the official Claude Code repository (checked October 4, 2026; all are open, with no response from Anthropic)

Every one of them happens right after a tool runs or a subagent reports back. Most follow English output or logs, but in #98633 replies turned English even when the subagent's report was in Japanese. Reading English as the trigger is shared with Pattern 1 in §4, but where Pattern 1 builds up gradually over a long stretch of work, Pattern 4 switches to English abruptly, right after a single tool run. It also differs in that the language setting did not stop it.

In the author's own logs, English in the mid-task messages roughly quadrupled

The author has been giving Claude Code (the Code tab of the desktop app) requests in Japanese every day, and tallied those logs by model. Splitting the replies into "short messages before running a tool" and "the final reply of the turn" makes the difference clear.

Source: the author's own Claude Code session logs (one person, tallied October 4, 2026). Only replies of 60 characters or more that followed a request written in Japanese were counted. Turns were delimited by the user's messages and by completion notices from work running in the background. A reply was counted as English when Japanese made up less than 8% of its characters outside code and URLs. The kind of work differed between the two periods, so the gap cannot be put down to the model alone

Almost all the English came in the short mid-task messages: brief lines announcing the next step, such as "Deploying this batch." Overall, even with Opus 5.5, about 98% of final replies stayed in Japanese. The figure jumps from day to day, though: on October 3, 11 of 112 final replies (about 10%) were in English. On days like that, a whole work report came out in English, or so did the brief line written while waiting for background work to finish (such as "Waiting for the remaining 5 agents."). Of the 16 projects where at least 15 mid-task messages could be counted for each model, the English share rose in 13 and fell in just one.

The mid-task messages are what someone watching the work sees most. Even if the final summary is in your language, the screen fills with English while the work is underway, which makes it easy to feel that Claude has suddenly switched to English.

Fixes reported not to work

• The language setting and CLAUDE.md. #96326 happened with both in place. #98633 had the instruction in both CLAUDE.md and auto memory
• Correcting it in the conversation. Many reports say it switches back right away, then turns English again the next time a tool runs

A fix reported to work: a hook that restates the language after every tool run

The tech blog SmartScope tested a hook that inserts "write messages to the user in Japanese" every time a tool runs (September 30, Claude Code 2.1.285, Opus 5.5). It reports that without the hook, 22 of 26 replies were in English; with it, all 27 were in Japanese, and over about three hours and 82 replies only one came out in English.

The mechanism follows the official hooks reference. When a PostToolUse hook, which runs after a tool finishes, returns additionalContext, that text is attached alongside the tool result, and Claude reads it before its next reply. Right after reading English output, the instruction about your language arrives as the most recent thing in the context.

A minimal example following the official format is below. Add it under hooks in ~/.claude/settings.json (replace Spanish with your own language). To restate the language when a tool fails as well, put the same thing in PostToolUseFailure.

{
  "hooks": {
    "PostToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PostToolUse\",\"additionalContext\":\"Write all messages to the user (progress updates, questions, final report) in Spanish, even when tool output is in English.\"}}'"
          }
        ]
      }
    ],
    "PostToolUseFailure": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PostToolUseFailure\",\"additionalContext\":\"Write all messages to the user (progress updates, questions, final report) in Spanish, even when tool output is in English.\"}}'"
          }
        ]
      }
    ]
  }
}

Three things to keep in mind:

• The measured effect comes from a single environment. The author checked the format against the official documentation but did not measure the effect of this example
• The text piles up in the history every time a tool runs. Each insertion is short, but over a long task it gradually uses up context
• Leaving out the matcher makes it run for every tool (per the official reference). If several tools run in parallel, it is inserted once for each. If you would rather have it once, there is also a hook called PostToolBatch that runs only once after a batch of tools finishes, but no report measuring its effect has turned up yet

Is the cause the model or Claude Code?

Even the users who reported it disagree, and there is no official explanation. #96601 asks whether the way the output style is injected changed or whether it is a regression in the model, but as of October 4 no one has answered. Reading the changelog through 2.1.288 (October 2) turned up no fix related to language.

3. Researchers have a name for it: language confusion

In research, a model answering in a language other than the one requested is called language confusion. A paper by Marchisio et al., presented at EMNLP 2024, a major international conference on natural language processing, built a benchmark that measures it across 15 languages and compared the leading models.

The conclusion is blunt. The paper reports that even the strongest models fail to respond consistently in the correct language when the setup crosses languages. "Crossing languages" here means the request is written in English while the answer is asked for in another language.

Figures are the share of responses in which every line was in the correct language (line-level pass rate). Source: Table 3 of Marchisio et al., "Understanding and Mitigating Language Confusion in LLMs" (EMNLP 2024)

How badly a model misses also depends heavily on the target language: in the same cross-lingual setting, Llama 3 70B Instruct passed 61.1% for Spanish but only 1.4% for Japanese. The paper further shows that models whose instruction tuning centered on English confuse languages more easily, and that the problem gets worse with complex requests and higher temperature settings. Confusion comes in two forms: a whole line switches to another language, or a single English word slips into a sentence written in the requested language. The "check" line in the opening figure sits right between the two.

Work in Claude Code tends to look a lot like this cross-lingual setup. Even when your request is in your own language, most of the code it reads, the command output and the error messages are in English. The further the work goes, the larger the share of English in the context.

4. Pattern 1: the further the work goes, the more English creeps in

This is the most common pattern. Report #32181 (March 2026, Claude Code 2.1.71, Opus) records the shift in three stages. That is the opening figure. The reporter wrote that the drift toward English grew in proportion to how code-heavy the work was, and that it happened during ordinary work, with neither compaction nor plan mode involved.

One more point matters: Claude itself did not notice that it had switched. Because it does not notice, it does not switch back on its own either.

This report was closed automatically after a period of inactivity (marked "not planned"). It was not closed because the problem was fixed. No fix has been announced either, so it is up to you, the user, to act.

5. Pattern 2: back to English right after compaction

When a conversation gets long, Claude Code summarizes the exchange so far to free up context. That is compaction (the mechanics are covered in detail in Should you run /compact on a schedule in Claude Code?).

Report #59299 (May 2026, Claude Code 2.1.141) describes a conversation carried out in Spanish that went back to English immediately after compaction. The reporter said it had never once worked correctly, and this report too was closed automatically after going inactive.

The official documentation section What survives compaction explains why it happens.

Source: rows relevant to language instructions, excerpted from Claude Code documentation, What survives compaction

If all you did was ask, partway through the conversation, for replies in your language, that request lands on the side that gets summarized. If the summary does not preserve the fact that you were speaking another language, the next reply can fall back to English.

Conversely, instructions in the system prompt are not affected by compaction. That mechanism is exactly why the setting in §7 holds up through compaction.

6. Pattern 3: not English, but a different language entirely

This one is a little unusual. In report #46846 (April 2026, Sonnet 4.6, VS Code extension), the user's CLAUDE.md told Claude to always reply in Traditional Chinese as used in Taiwan and never use Japanese, Korean or Simplified Chinese, yet Claude replied in Japanese and Korean.

The reporter describes three characteristics.

• It happens right after commands that return English output, such as git and gh
• Even with the instruction written in both CLAUDE.md and auto memory, it comes back across sessions
• Claude apologized in Japanese, said it would rewrite the answer in the correct language, and then wrote the rewrite in Japanese too

According to the report, the codebase contained only Traditional Chinese and English, with no Japanese or Korean material anywhere. It looks as if Claude, pulling away from English, slid into another East Asian language close to the one requested, but that is only a reading of what the report says, and the cause has not been confirmed.

What can be said is that instructions written only in CLAUDE.md are sometimes not followed. CLAUDE.md is re-read after compaction, yet there are cases where the language still breaks, so combining it with the setting below is the safer course.

7. The basic fix: the language setting

Claude Code has a setting called language that pins the language of its replies. According to the official changelog, it was added in 2.1.0. You add one line to a settings file (replace spanish with your own language).

{
  "language": "spanish"
}

The official settings reference describes how it works in three points.

• The value you write goes straight into the system prompt as an instruction to always reply in that language. That is why, as §5 showed, it keeps working after compaction
• There is no fixed list of language names. Any name Claude can understand works. The flip side is that the value is not validated, so a misspelling raises no error and reaches Claude misspelled
• The same value also sets the language for voice input and for automatically generated session names. Voice input does have a list of supported languages

Which file you put it in determines how far it reaches.

Source: Claude Code documentation, Settings files and precedence

It is not a cure-all, though.

• The interface stays in English. According to report #77976 (July 2026, 2.1.211), what the setting switches to your language is Claude's replies and the wording of the questions Claude puts to you. Dialogs that ask permission to run a tool, and their buttons, stay in English
• Its effect on Pattern 3 has not been confirmed. #46846 above specified the language in CLAUDE.md, and no report has turned up on whether replies still turn into another language when the language setting is used
• Pattern 4 has been reported even with this setting in place. As described in §2, combine it with a hook that restates the language after every tool run

If you are unsure where a setting lives or which one takes precedence, open /config inside Claude Code to see your current settings.

8. Claude in the chat apps, and ChatGPT

Claude in the browser and the apps has no dedicated setting that pins the reply language. The official help article explains how to change the interface language, and then notes that whatever the language setting, Claude converses in the language you use.

ChatGPT is built along similar lines. The language setting described in OpenAI's official help article detects your browser or phone language and matches the interface language to it, and it does not say that it pins the reply language.

Both do, however, have an instruction field that applies to every conversation: account-wide instructions in Claude's settings (official help) and custom instructions in ChatGPT (official help). Writing "Always reply in [your language]" there saves you from repeating it every time. Still, it is one instruction among others rather than a mechanism that locks the language, so in the situation below it is safer to put the language in the request as well.

In the chat apps, English is most likely to appear when you paste in English text and ask for a summary or translation. That is precisely the cross-lingual setup from §3, so end your request with "Please answer in [your language]" to be sure.

Where to find these fields, their character limits and how to write them are covered in our guide to custom instructions in ChatGPT, Claude and Gemini.

9. September 2026 (unconfirmed): long sessions where the output itself breaks down

From here on, this is an ongoing story whose cause Anthropic has not acknowledged. Labels separate how certain each point is.

✅ Two similar reports on September 13 and 14

Report #94016 (September 13) came from the Code tab of the desktop app, running Opus 5, in a long session of more than 100 exchanges in Japanese. Cached input stood at roughly 880,000 tokens. Partway through a reply, the conversation format broke down: Claude invented a fictional "user question" and its own "answer", then printed about 7,400 characters of the configured output style's instructions to the screen. All of it happened inside a single reply, and it was not an outside attack.

Report #94218 (September 14, Claude Code 2.1.270, VS Code extension) covers a session that ran for more than six hours with Opus 5. Among its breakdowns, which included inventing user messages and carrying on the conversation with them, internal strings leaking into the body text, and fabricating results for tools that never ran, it records a reply in English to a conversation that had been conducted entirely in Japanese.

As of October 4, 2026, neither has an official response, and both remain unresolved. Similar breakdowns have happened before; a case where tool calls come out as plain text is covered in Claude Code prints "court" and raw invoke tags.

🟡 What they share: Opus 5, Japanese, and an extremely long session

The two reports have Opus 5, Japanese, and an extraordinarily long context in common. What stands out is that on September 3, Claude Code 2.1.260 changed auto-compaction for Opus and Fable with a one-million-token context so that it no longer triggers until just short of the limit (stated in the changelog).

As a result, it became easier for sessions to keep running for a long time after swelling close to 900,000 tokens. The 880,000 tokens in the report falls in that range. However, no one has verified that this change causes the breakdowns. What can be said is that the timing and the context size overlap, and no more.

🔴 The cause, and whether Anthropic will fix it

The cause of the breakdowns, its relationship to the 2.1.260 change, and any plans for a fix are all unknown, with no official answer.

What you can do for now

• Do not let the context run all the way up toward one million tokens. As the official documentation describes, passing a token count as in /autocompact 500k moves auto-compaction earlier. Starting a new session at a natural break also works (for how to see what fills your context, see Claude Code: What Is Actually Eating Your Context?)
• If a reply contains fictional user messages or internal strings you do not recognize, end that session. #94218 records the breakdown getting worse the longer the session continued on top of the broken context
• Keep the language setting in place. It works against Pattern 1, the gradual drift into English. Whether it also prevents the output format itself from breaking down is unknown

Summary

• Answering in a language other than the one requested is a general weakness confirmed by research, not a problem unique to Claude
• The Claude Code reports covered here were either closed automatically without a fix or are still open, so preventing it is up to you
• The basic fix is the language setting. It sits in the system prompt, so it survives compaction
• Pattern 4, which grew from late September 2026 (short mid-task messages turning English with Opus 5.5), has not always been stopped by the language setting alone. There are reports of preventing it with a hook that restates the language after every tool run
• Claude in the chat apps and ChatGPT have no dedicated setting that pins the reply language, so put it in the instruction field that applies to every conversation, and when you paste English text, state the language in the request too

FAQ

Q1. In the language setting, should I write "spanish" or "español"?

According to the official reference, there is no fixed list, and any language name Claude can understand works, because the value goes into the system prompt as written. The value is not validated, though, and a misspelling raises no error. The same value also sets the voice input language, which does have a list of supported languages, so the safe choice is to follow the official example and use the English name, as in "spanish".

Q2. I set it, but some English is still left.

There are three possibilities. The first is the interface: tool permission dialogs and buttons are outside the scope of this setting. The second is Pattern 4 from §2: with Opus 5.5, there are reports of the short messages between tool runs turning English even with the setting in place. Try a hook that restates the language after every tool run. The third is the long-session breakdown from §9, which may be a separate problem from the setting. If your context has grown past several hundred thousand tokens, try again in a new session.

Q3. How is this different from writing "always reply in [your language]" in CLAUDE.md?

Both keep working after compaction, but they get there differently. The language setting goes into the system prompt, while CLAUDE.md at the project root is re-read from disk after compaction. As §6 showed, there are reports of CLAUDE.md instructions being ignored, so putting the language in the setting is the more reliable choice.

Q4. What happens if I just leave the English alone?

With Pattern 1, the longer you leave it, the stronger the English tends to get. The reporter of #32181 wrote that Claude did not notice the switch and never switched back on its own. The reliable approach is to nudge it back as soon as you notice, or to prevent it with the setting.