Claude Code Garbled Text and Language Settings by Symptom

If you write code in a language that is not English, Claude Code will eventually do something strange to your text. It answers in English when you wrote in Korean. Characters turn into boxes or overlap each other. A file that is clearly there cannot be found.

These look like one problem. They are five, and each has a different cause. Find your row first.

This article reflects Claude Code 2.1.241, checked on August 24, 2026.

Set the reply language in settings.json

If Claude keeps answering in English no matter what you write, one line fixes it. Open ~/.claude/settings.json and add this.

{
  "language": "한국어"
}

Create the file if it does not exist, or add the key if you already have other settings there. You can also ask Claude Code to do it for you.

Add or update the "language" value in ~/.claude/settings.json so replies default to Korean. Keep my existing settings.

That single setting changes three things at once: Claude's default reply language, the language for voice dictation, and the language of the session titles that get generated for you.

The official docs show English names like "japanese", "spanish", and "french" as examples, but the language's own name works too. "한국어" and "日本語" both do the job. If you have been typing "answer in Korean" at the top of every prompt, this line ends that.

You can also put language instructions in CLAUDE.md if you want it per project or need something more specific. For changing the language alone, the setting is simpler.

Garbled or overlapping text: run /terminal-setup

Characters render as boxes, smear together, or turn into the wrong glyphs entirely. This shows up most often inside the integrated terminal of VS Code, Cursor, or Devin Desktop.

The official docs point at GPU acceleration in the terminal. Your editor draws the terminal with the graphics card, and that path mishandles wide glyphs.

Run this inside Claude Code.

/terminal-setup

It sets your editor's terminal.integrated.gpuAcceleration to "off". Reload the editor window afterward. You can do it by hand instead: find that setting in your editor and set it to off. To undo it, set it back to "auto" and reload.

/terminal-setup does one more thing worth having. It adds the key binding that makes Shift+Enter insert a newline instead of sending. Run it once even if your text renders fine. Run it from the terminal itself, not inside tmux or screen, because it writes to the host terminal's configuration.

A separate bug exists in the VS Code extension: text in the question cards can render as plausible but wrong characters. If your terminal is clean and only the cards are broken, that is this one, and it is still open.

When the IME covers what you are typing

You start typing, and the candidate window sits on top of the input area, or the whole line shifts. This is usually the terminal program's problem, not Claude Code's. The project tracker has a report of the IME candidate window covering the input area in Windows Terminal, and another of selection highlights landing in the wrong place when you drag over CJK text in JetBrains editors. The second one reproduces in that terminal and nowhere else.

So the first thing to try is a different terminal. If you were using your editor's integrated terminal, open Claude Code in the system terminal instead: Terminal or iTerm2 on macOS, Windows Terminal on Windows. If the symptom disappears, the editor is the cause and you now know where to file.

Non-ASCII paths break file search on Windows

The file is right there, and Claude reports that it cannot be found. On Windows, file search fails when the working path contains non-ASCII characters. It is reported against a Korean-language Windows setup, and it triggers on the working folder's path.

The issue is still open. Until it is fixed, the workaround is to take non-ASCII characters out of the working path. Move the project from a folder named in your own language to something like C:\projects.

Honestly, keeping development folders on ASCII paths is the safer habit anyway. This is not specific to Claude Code. Terminal tooling in general has a long history of tripping over paths it did not expect.

Shortcuts stop working while the IME is on

You press Ctrl+V and nothing happens. You check your key bindings, find nothing wrong, and start doubting yourself.

Ctrl combinations can fail to register while the IME is in composition mode. The tracker has this reported for the Korean two-set input method on macOS, with the note that the same shortcut works normally once you switch back to Latin input.

The fix is unsatisfying but immediate: toggle back to Latin input before you reach for a shortcut. What matters more is that you did not misconfigure anything. This is a known issue, and it is worth knowing before you spend an evening rebuilding your key bindings.

When the box drawing itself breaks

Every symptom above involves your text. There is one more kind where Claude Code's own interface breaks, and it hits English-only users too. Progress bars, spinners, box-drawing lines, bullets, and ellipses render as mojibake, most often on Windows terminals.

This is not the GPU path, so /terminal-setup will not help. It comes down to what your terminal can encode and which font it falls back to. Windows Terminal with a font that carries the box-drawing range handles it; older console hosts often do not. There are also reports of the interface degrading only after a long session, where it starts clean and drifts into garbage, which points at output corruption rather than font coverage. Restarting the session clears that one.