Using Claude Code in German, or Any Other Language

Claude Code works in German, and in three decisions that have nothing to do with each other: the language of your orders and its answers, the language of your rules file, and the language of the documentation. The first takes one sentence to set, the second is your free choice, and the third has a newer answer than most guides give: the Claude Code documentation exists in full in German, checked on 23 September 2026 at code.claude.com/docs/de.

The thing that goes wrong most often is not the language itself. It is the assumption that a request made in the chat outlives the session. It does not. And a rule in CLAUDE.md does outlive it, but according to Anthropic's own documentation it is a hint rather than a switch.

Can I use Claude Code in German?

Yes, completely, once you keep three things apart. Almost every guide stirs them into a single question, and that is where the surprises come from.

Definition: The reply language is the language the agent talks to you in. The rules language is the language your CLAUDE.md is written in. The product language is the language of what gets built: identifiers in the code, commit messages, text a user sees. All three are set separately, and you can pick a different language for each.

The model infers the reply language from the conversation. Anthropic's developer documentation says that for production applications you should state the target language explicitly, and that the most reliable place for it is the system prompt, because an instruction there stays stable across every turn of a conversation (Multilingual support, platform.claude.com). In the terminal, your CLAUDE.md is what stands in for the system prompt.

How do I set the reply language for good?

With one line in a CLAUDE.md, not with a request in the chat. The difference is not convenience. It is the number of places you are needed.

The file is loaded into context at the start of every session. It exists in several locations, and the two that matter day to day are:

1. CLAUDE.md in the project. Applies to that project, and belongs in the repository so it applies to everyone working in it.
2. ~/.claude/CLAUDE.md. Your personal preferences across every project on your machine. This is where a language rule belongs if you work in German generally.

Larger projects can also use .claude/rules/ with one file per topic, and rules there can be scoped to file paths so they only load when the agent works with matching files (How Claude remembers your project, code.claude.com).

The line itself needs no craft. What it needs is a decision about what else, beyond the reply, should be in German:

## Language

Answer in German, informal address.
Code, identifiers and commit messages stay English.
User-facing copy is German, and carries no em dashes.

Three lines, three separate decisions. Write only the first and you get German answers, then German variable names in an English codebase, and you notice in review.

Why does it still answer in English sometimes?

Because CLAUDE.md is not a switch. It is context, and the documentation says so directly: Claude treats these files "as context, not enforced configuration" (code.claude.com/docs/en/memory).

The practical consequence sits in the same document: "Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best." A short unambiguous rule is followed more reliably than a paragraph restating it.

The most common cause of an English answer despite a German rule is something else again, and the documentation names it: "if two rules contradict each other, Claude may pick one arbitrarily." A language rule in ~/.claude/CLAUDE.md and an English-only convention in the project are exactly that kind of contradiction. Resolve it and you need no third rule reinforcing the first.

When something has to be blocked regardless of what the model decides, the mechanism for that is a PreToolUse hook, not a more forceful line in the rules file. For the reply language that is rarely worth the effort: a wrong language is visible immediately, it damages nothing, and one sentence corrects it.

Is the interface in German, and are the docs?

The docs yes, the command names no. This is where most non-English guides are out of date.

The complete Claude Code documentation is available in German at code.claude.com/docs/de. Retrieved on 23 September 2026: the page about the rules file is titled "Wie Claude sich Ihr Projekt merkt", is marked up as a German-language document, and had been updated the day before (code.claude.com/docs/de/memory). The developer documentation is German too, at platform.claude.com/docs/de.

What is not translated are the commands. Even in the German edition they are /memory, /config and /help, and the files are still CLAUDE.md and .claude/rules/. That is a necessity rather than a gap: a translated command name would break every guide on the internet for that reader.

The Claude apps, web and desktop, do have a real language setting. Support lists eleven languages including German, and states that you can still chat in any language regardless: Claude converses with you in the language you use (support.claude.com). Interface language and conversation language are two things there as well.

Is the model worse in German than in English?

Measurably a little, practically not much. Anthropic publishes the numbers itself.

German comes in at 97.0 percent of English performance, and 94.3 percent with Claude Haiku 4.5 (Multilingual support, platform.claude.com).

That number deserves an honest reading, which is missing from most of the guides that quote it. What was measured is knowledge and reasoning through MMLU, not programming. It says nothing about the quality of code produced from a German order. What it does say is that the language of your order is not where your result is won or lost. Three percentage points disappear next to the difference between an order with context and an order without one, which we counted in our own order in What is vibe coding.

A second point from the same source is useful for any non-English work: if an application lets users pick a language at runtime, that choice belongs in the system prompt rather than being inferred from the user's message.

What language should the rules file be written in?

The one that helps the file, not the one the product speaks. Our own files make the case, and at first glance the result looks contradictory.

The rules file for this site is English, 3,523 words long, and every sentence a visitor reads here is German. Among other things that file carries the rule that the German half of the product uses informal address, and the rule that no em dash appears anywhere as punctuation. Both rules are written in English and both govern German text only. They work anyway, because the language of the instruction and the language of the output are independent. That is the answer to the question this section opens with.

The two files we do write in German are the two that produce German sentences themselves: the skill that writes this article, and the one that builds the author pages. There the language is the subject rather than the packaging. An instruction about German sentence structure, phrased in English, is one translation more than the job needs.

That turns into a rule you can adopt without seeing our files:

• English when the file describes workflow, architecture and prohibitions. Those terms come from English anyway, and the file stays readable for anyone who joins.
• Your own language when the file dictates phrasing that has to appear verbatim in the output.
• One language per file. A rules file that switches between two is the precursor to two rules that contradict each other.

What belongs in German, and what does not?

Everything a person reads while using your product. Everything else follows your project's convention, which is English in case of doubt.

The practical cut runs like this:

1. Your orders in the terminal: your own language, if that is the language you think in. The order is where you have to be precise, and you are more precise in your own language.
2. Code, identifiers, filenames, commit messages: the project convention. In almost every project that means English, including on all-German teams.
3. User-facing copy, user-facing error messages, customer documentation: German, and that belongs in the rules file, because otherwise it gets renegotiated on every second task.

What you still find less of in German is other people's examples. The documentation is translated, the mass of posts, error reports and discussions is not. When something breaks and you are stuck, the answer is almost always in English. That is the honest remainder of the language question, and it shrinks as more German-language material gets written.

Where do you start?

With one file and three lines, today, before you open the next session.

1. Create ~/.claude/CLAUDE.md and put the language rule in it once, for every project.
2. Separate the three decisions explicitly: answers, code, user-facing copy. Set only the first and you decide the other two by accident.
3. Read the German documentation once, instead of trusting guides that say it does not exist: code.claude.com/docs/de.

Which tool is the right one for the job we answered along the way you work in Claude Code vs Cursor, and what actually drives the monthly figure is in Claude Code Kosten, in German. In English, the Claude Code cost calculator puts a number on your own usage.

The layer above this is what turns a configured language into a way of working: the file with your rules, the order with context and limits, the counter-check, and eventually tasks that finish without you. That is what we teach, in German, in Das Claude Code System, four weeks with weekly live sessions. To see a session first, join a free live webinar. Every course is listed under Courses, and the people behind them are on About.