Accented characters not working in Codex on WSL2 terminal in VSCode

Do accented characters work in the VS Code terminal when you're not running codex in it? I'm wondering whether this is a VS Code terminal problem or a Codex bug.

Do accented characters work in the VS Code terminal when you're not running codex in it? I'm wondering whether this is a VS Code terminal problem or a Codex bug.

@etraut-openai

I’m having the same problem. Accented characters work fine in the VS Code terminal/WLS2 terminal, the issue literaly only occurs in the Codex CLI.

I tried setting the locale in WSL2 with:

sudo locale-gen pt_BR.UTF-8 && sudo update-locale LANG=pt_BR.UTF-8 LC_ALL=pt_BR.UTF-8

But it didn’t fix the issue.

v0.111.0 too

@etraut-openai I can confirm this is still happening for me, including on alpha.

Observation: In my Ubuntu terminal (WSL2), accent composition works normally outside Codex.
The issue happens only after entering Codex (inside Codex input). This started for me from
version 0.111.0.

## Environment

• Codex CLI: 0.112.0-alpha.11 (also reproduced on 0.111.0)
• OS: Windows + WSL2
• Keyboard layout: Portuguese (Brazil) ABNT2
• Terminal where it fails: VS Code integrated terminal (inside WSL2)
• Terminal where it works: regular shell in the same terminal when Codex is not running

## Repro

1. Open VS Code integrated terminal in WSL2
2. Run codex
3. Type accented Portuguese characters using key combinations (dead keys), for example:

• ' + a => á
• ' + e => é
• ^ + vowel => â, ê, ô
• ~ + vowel => ã, õ

## Actual

• Dead-key combinations do not compose accented characters inside Codex.
• ç (cedilha) works, but accents that depend on key combinations do not.

## Expected

• Input should match normal terminal behavior (same as outside Codex).

## Extra notes

• Locale changes in WSL2 did not fix it.
• Updating to alpha (0.112.0-alpha.11) did not fix it either.

@etraut-openai I prepared a focused fix for #13638 and kept it aligned with the contribution policy (no unsolicited PR
opened).

Compare link:
https://github.com/openai/codex/compare/main...rafael-agenticca:codex-upstream-fork:fix/wsl-vscode-dead-keys-13638-main?expand=1

Summary

• Reproduced on WSL2 + VS Code integrated terminal (PT-BR ABNT2), where dead-key composition fails only inside Codex.
• Root cause hypothesis: keyboard enhancement flags in this environment interfere with dead-key composition.
• Fix approach: disable keyboard enhancement flags specifically for WSL + VS Code terminal, preserving default behavior in

other environments.

• Scope: 1 commit, 2 files (codex-rs/tui/src/tui.rs, codex-rs/cloud-tasks/src/lib.rs), no unrelated refactors.

Validation

• Before: dead keys failed in Codex input (' + a, ^ + e, ~ + a), while ç worked.
• After: dead-key composition works correctly in Codex under the same environment.

If this direction matches the intended solution, could I receive an invitation to open an upstream PR?

I can confirm the issue: no accented characters are working. Additionally, even when using Caps Lock or manually switching between uppercase and lowercase letters, it still does not function properly.

Same here. All other CLI tools work as expected (Claude, Gemini CLI, Qwen...)

Same happens with DE-CH layout but for all shift-key combinations: https://github.com/openai/codex/issues/14391

I'm also experiencing the same issue on v0.117.0.

This might be the case for a switch to claude code, in Portuguese it's extremely irritating to not be able to use accentuation, specially to differentiate "é" from "e".

I thought this latest update would fix it, but it’s still the same. Guess I’ll have to use Opencode.

Three weeks ago, I reported that this issue occurred in version 0.111. We are already at version 0.117 and the bug has still not been included in the new releases.

I also published the bug fix, submitted a pull request, and shared the link to the fix in that post (https://github.com/openai/codex/issues/13638#issuecomment-4019174735).

I even reworked the fix from 0.116 to 0.117, which had to handle some new specifics:

• terminal detection moved away from the old path and is now using codex-terminal-detection
• in addition to the main TUI, the flow now also involves tui_app_server, which was still enabling PushKeyboardEnhancementFlags

It is already working for me in version 0.117, but with every new release, I have to fix and recompile Codex in Rust again just to work around this bug.

The issue is extremely simple to fix, but it seems it has not yet been prioritised for inclusion. This has become quite frustrating for all users running Codex inside VSCode on Windows.

I confirm that the error still exists in version v.0.117.0

I am also Brazilian but I don't have a ABNT2 keyboard to test. I always use English International layout on all my Windows machines. I couldn't replicate this issue with this layout:

<img width="604" height="312" alt="Image" src="https://github.com/user-attachments/assets/ea15454d-5e7c-4f61-9aec-b3076e4faa7d" />

Can anyone with this layout checkout the branch fcoury/fix-accented-chars and let me know if it solves this issue?

@rafael-agenticca @samuelrizzo se vocês tiverem um tempinho, conseguem me ajudar nesse teste?

_if you have time, can you help me with this test?_

@fcoury-oai no v0.118.0 funcionou no powershell do vscode, mas no WSL2 ainda segue sem funcionar, vou testar esse branch e te retorno

Excelente @samuelrizzo muito obrigado!

@samuelrizzo conseguiu testar?

_did you manage to test it?_

@samuelrizzo did you try it?

I can reproduce this on aarch64 Raspberry Pi + VSCode Remote SSH (non-WSL). The escape sequence ^[[13;1:3u leaks into the terminal and dead keys (circumflex, grave, etc.) produce no accented character.

Root cause in codex-rs/tui/src/tui/keyboard_modes.rs:

// keyboard_enhancement_disabled() line 21
let is_vscode_terminal = is_wsl && running_in_vscode_terminal();

On non-WSL Linux the is_wsl short-circuit makes is_vscode_terminal always false, so the kitty protocol is enabled even though the VSCode PTY can't compose dead keys under it.

Fix — remove the WSL guard (two-line change):

// Before
let is_vscode_terminal = is_wsl && running_in_vscode_terminal();
keyboard_enhancement_disabled_for(disable_env.as_deref(), is_wsl, is_vscode_terminal)

// After
let is_vscode_terminal = running_in_vscode_terminal();  // no WSL guard
keyboard_enhancement_disabled_for(disable_env.as_deref(), is_vscode_terminal)

running_in_vscode_terminal() already reads Linux-side TERM_PROGRAM first, and the cmd.exe Windows interop probe is only reached on WSL — so no regression for the existing WSL+VSCode path. On Remote SSH, VS Code injects TERM_PROGRAM=vscode via shell integration, so detection works out of the box.

I've prepared a ready-to-merge branch with updated tests: https://github.com/yaco16/codex/tree/fix/vscode-remote-ssh-dead-keys

Workaround until this lands:

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

Thanks, this looks like a real follow-up, but it is a different environment from the original WSL2 report. I opened #22839 to track the native Linux VS Code Remote SSH case separately. I am testing a narrow follow-up that extends the keyboard-enhancement guard to Linux VS Code terminals while keeping the original WSL fix intact.