[BUG] Language setting does not enforce diacritical marks — accents/cedillas dropped in non-English output
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When language is set to a language that requires diacritical marks (e.g., "pt-BR", "vi", "fr", "cs"), Claude frequently drops accents, cedillas, and other diacritics from its text output — even though it technically responds in the correct language.
For example, with language: "pt-BR":
| Expected | Actual output |
|----------|---------------|
| informação | informacao |
| não | nao |
| código | codigo |
| sessão | sessao |
| você | voce |
This happens even when CLAUDE.md includes explicit instructions like "NEVER omit accents" with detailed examples. The problem gets significantly worse after context compaction and in long sessions.
Related but distinct from:
- #32181 (language drift to English — my issue is about accent loss while staying in the target language)
- #32107 (language ignored in auto-accept phase — different trigger)
- #1599 (curly quotes clobbering — different character class)
What Should Happen?
When language is set to any locale that requires diacritical marks, Claude should maintain full orthographic correctness — including all accents, cedillas, tildes, umlauts, circumflexes, etc. — in all text output, at all times, including after context compaction.
Error Messages/Logs
No errors — the output is syntactically valid, just orthographically wrong.
Steps to Reproduce
- Set
language: "pt-BR"in~/.claude/settings.json(or any language with diacritics) - Optionally add a CLAUDE.md rule reinforcing accent usage
- Start a session and work on a coding task — accents will be inconsistent from the start
- Continue working until context compaction kicks in
- After compaction, accent dropping becomes noticeably worse
- Explicitly telling Claude "use accents" fixes it temporarily, but it regresses within a few messages
Root cause investigation
I dug into the compiled CLI source (cli.js) to understand why this happens. Found three contributing factors:
1. The language instruction template is too vague
The function that injects the language setting into the system prompt (around line 6230) generates:
# Language
Always respond in pt-BR. Use pt-BR for all explanations, comments, and communications
with the user. Technical terms and code identifiers should remain in their original form.There's zero mention of diacritical marks, orthographic correctness, or character fidelity. The model interprets "respond in pt-BR" loosely and treats accent-less Portuguese as acceptable.
2. CLAUDE.md instructions are injected with a weakening disclaimer
The function that wraps CLAUDE.md content (around line 6315) adds:
IMPORTANT: this context may or may not be relevant to your tasks.
You should not respond to this context unless it is highly relevant to your task.This actively tells the model that CLAUDE.md rules are optional context, not binding directives. So even explicit "NEVER drop accents" rules in CLAUDE.md get deprioritized — the model decides accent rules aren't "highly relevant" to a coding task.
3. Context compaction doesn't carry language rules
The compaction/summarization function (around line 2286) sends conversation history to be summarized without including language or locale instructions. The summarization model has no reason to preserve diacritics in the summary, so the compacted context comes back with degraded text. Subsequent messages inherit this degraded context.
Suggested fix
The language instruction template should explicitly enforce orthographic fidelity. Something like:
# Language
Always respond in ${language}. Use ${language} for all explanations, comments, and
communications with the user. Technical terms and code identifiers should remain in
their original form.
Maintain full orthographic correctness for ${language}, including all required diacritical
marks, accents, cedillas, and special characters. Never produce text that omits characters
required by the language's orthographic rules.Additionally, the CLAUDE.md disclaimer should not apply to language/formatting rules — these are always relevant regardless of the task.
And the compaction prompt should include the user's language setting so the summarizer preserves proper orthography.
Claude Model
Opus
Is this a regression?
I don't know
Claude Code Version
2.1.72 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
This affects every language that uses diacritical marks — Portuguese, French, Vietnamese, Czech, Turkish, Spanish, German, etc. The issue is structural in how the language setting is injected and how CLAUDE.md instructions are framed. Happy to help test a fix.
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Aware of the related issues — here's how this one differs:
All three report the symptom. This issue adds the root cause analysis from the compiled CLI source, identifying three specific contributing factors in the prompt assembly pipeline:
r1z()~line 6230) says "Always respond in X" but never mentions diacritical marksThe accompanying PR (#32894) provides a plugin workaround, and the issue body proposes specific fixes for the core CLI.
Should be kept open alongside #14131 as the diagnostic counterpart — #14131 tracks the user-facing problem, this one tracks the technical root cause and fix.
+1 — Experiencing the exact same issue with Spanish (es-PE) accents configured via CLAUDE.md.
Additional data point from our case (#34779): the accent dropping is not constant — it worsens progressively during long sessions. Early messages respect the CLAUDE.md instructions perfectly, but after ~30+ tool calls (when context compression likely kicks in), accents start dropping inconsistently.
This suggests CLAUDE.md instructions may be getting deprioritized or truncated during automatic context window compression.
Environment: macOS, Claude Code 2.1.76, Opus 4.6, locale C.UTF-8, 4 chained CLAUDE.md files.
we've seen this with generated code comments and variable names. the model seems to default to ASCII-safe characters when writing to files even if the language setting says otherwise. for our use case (writing social media content), we work around it by explicitly including example text with the correct diacriticals in the prompt. not ideal but it helps.
our content generation pipeline that handles non-ASCII text: https://github.com/m13v/social-autoposter/blob/main/skill/SKILL.md - includes explicit content rules with examples.
This issue deserves much more attention. The root cause analysis here is the most thorough I've seen in this tracker, and it explains a cascade of bugs that are being reported separately across multiple languages. Cross-linking for visibility:
Same structural bug, other languages:
oncalllabel)I filed #26128 (Spanish diacritics) separately; it was closed as duplicate/stale without resolution and without the underlying structural issue being fixed. The comment at #14131#issuecomment-4165081698 adds the Spanish case with a cross-language summary.
The issue is structural, not per-language. The three root causes identified here affect every non-ASCII language equally:
These are three lines of code. The fix is documented in this issue. The fact that this affects the professional usability of Claude Code for every non-English speaker in the world — and that the root cause has been identified — makes this a high-priority fix, not a stale issue.
Spanish, German, Portuguese, French, Vietnamese, Czech, Japanese, Chinese, Arabic, Armenian. This is not a niche edge case. The majority of Claude Code users do not write in English.
For folks hitting this: would you mind running
/feedbackand sharing the ids here? Would be helpful so we can repro + debug@bcherny
f5364169-21c5-4549-a9c1-61a70fcf1ba6
4b61195c-8764-4a03-97a3-eeab5f35c391
@bcherny Feedback ID: eced2dcf-2976-461f-988f-32811208a031 — fresh session, first response already shows the bug: "geloescht" instead of "gelöscht", "loeschen" instead of "löschen", "ausser" instead of "außer". No context compaction — happens immediately from the start.
Note: the bug is random but guaranteed — it occurs in every single session without exception, sometimes immediately, sometimes mid-session. There is no session where it does not appear eventually.
I am also the author of the original issue #14131 (filed December 13, 2025) which documents the same bug for German specifically.
https://github.com/anthropics/claude-code/issues/14131#issuecomment-4165138904
I confirm. French outputs.
b460afc9-f245-4f28-9a2d-2e6843daad0b
Thanks all for the feedback ids! Fix going out tomorrow.
Same issue here with Italian. By default, Claude Code consistently writes apostrophes instead of accented vowels, e.g.
perche'instead ofperché,e'instead ofè,piu'instead ofpiù,citta'instead ofcittà.When explicitly prompted to use proper accented characters (è, é, à, ò, ù), it does switch and writes them correctly, but only until context compaction kicks in or the session gets long enough, then it reverts back to apostrophes.
This is especially annoying because in Italian, apostrophe-instead-of-accent is considered a spelling mistake (not just a stylistic choice), and having to remind Claude every few messages to write proper Italian gets old fast.
My language setting is
english. I don't want to switch it toitalianbecause I frequently work in English too. Claude should be able to use correct accented vowels when responding in Italian regardless of the language config.Adding rules to CLAUDE.md doesn't stick either, same regression pattern described above.
Feedback ID with reproduction:
14d6be4b-9ae3-4ed5-8162-5595ddc5f2b5This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.