Repository navigation
Description
Description
The system prompts contain an instruction that causes LLMs to avoid non-ASCII characters by default:
Default to ASCII when editing or creating files. Only introduce non-ASCII or other Unicode characters when there is a clear justification and the file already uses them.
This instruction appears in all model-specific prompt files:
codex_header.txtanthropic.txtbeast.txtgemini.txtqwen.txttrinity.txtcopilot-gpt-5.txt
While the intent is to prevent encoding issues in code files, LLMs interpret this broadly and apply it to all output, including conversational text. This effectively breaks support for any language that uses diacritics or non-Latin scripts.
Affected Languages
| Language | Missing Characters | Example |
|---|---|---|
| Portuguese | ç, ã, á, é, í, ó, ú, ô, ê | "ação" → "acao" |
| Spanish | ñ, á, é, í, ó, ú, ü | "año" → "ano" |
| French | é, è, ê, ë, à, â, ç, ô, î, ï, û, ù | "français" → "francais" |
| German | ä, ö, ü, ß | "größe" → "grosse" |
| Polish | ą, ć, ę, ł, ń, ó, ś, ź, ż | "żółć" → "zolc" |
| Turkish | ç, ğ, ı, ö, ş, ü | "güneş" → "gunes" |
| Nordic (Swedish, Norwegian, Danish) | å, ä, ö, æ, ø | "blåbär" → "blabar" |
| Vietnamese | ă, â, đ, ê, ô, ơ, ư + tones | Severely broken |
| Russian, Ukrainian, Greek | Cyrillic, Greek alphabets | Completely unusable |
| Chinese, Japanese, Korean | CJK characters | Completely unusable |
| Arabic, Hebrew | RTL scripts | Completely unusable |
Plugins
none
OpenCode version
1.1.53
Steps to reproduce
-
Configure opencode with GPT-5.2
-
Add a user prompt requesting output in a non-English language, e.g.:
Always respond in Brazilian Portuguese with correct spelling and accents. -
Ask any question
-
Observe that the response lacks proper diacritics/accents
Expected: "A função executa a ação corretamente."
Actual: "A funcao executa a acao corretamente."
Suggested Fix
Scope the ASCII constraint to code file editing only, and explicitly allow Unicode in conversational output:
## Editing constraints
-- Default to ASCII when editing or creating files. Only introduce non-ASCII or other Unicode characters when there is a clear justification and the file already uses them.
++ When editing or creating source code files, prefer ASCII for identifiers and comments unless the project already uses non-ASCII characters. This constraint does NOT apply to conversational responses, documentation, or user-facing text—use proper Unicode characters as appropriate for the language.
### Screenshot and/or share link
_No response_
### Operating System
Ubuntu 24.04.4
### Terminal
Ghostty 1.2.3
Activity
github-actions commentedon Feb 7, 2026
This issue might be a duplicate of existing issues. Please check:
The core issue in #12609 is that system prompts impose ASCII-only constraints globally, affecting all output including conversational text in non-English languages. This is distinct from the avatar emoji rendering issue but shares related Unicode handling concerns.
Feel free to ignore if none of these address your specific case.
diegonix commentedon Feb 16, 2026
I know there are more important features and bugs to address, but OpenCode is now a global project with users all around the world. Please fix this for us.
There is a damn system_prompt preventing the LLM from doing what it does best - writing correctly in a human language.
micha149 commentedon Feb 25, 2026
This also affects all artifacts in a spec driven workflow. I already was wondering where this problem comes from. So… would be nice to see that fixed.
LackesLab commentedon Mar 17, 2026
Any decisions made wrt this issue? OpenCode simply ignores my instruction to use "ä, ö, ü" etc. Couldnt we make this adjustable? Would be a huge benefit when working on non-coding Tasks
bastienlimbour commentedon Apr 24, 2026
This issue is still present and very annoying. Any LLM used in OpenCode removes all accents whenever it edits a Markdown file in French. Is there any update on a fix for this problem?
diegonix commentedon Apr 24, 2026
I have build a custom agent and force it to use language correctly including diacritics with a session with DOs and DONTs
alfredocristofano commentedon Apr 25, 2026
Can confirm this affects Italian as well — accented characters (è, é, à, ì, ò, ù) are consistently stripped or replaced in conversational output. The proposed fix to scope ASCII constraints to code files only would resolve this.
jonimake commentedon Jun 12, 2026
When is this going to get fixed? The system prompt is broken, it doesn't work as intended. I'd even go as far as remove it completely.
diegonix commentedon Jun 12, 2026
It's such a simple change. But these guys prefer to keep posting garbage on X instead of filtering issues. And if we propose a PR, it'll just get lost in the mud.
github-actions commentedon Aug 12, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.