Dead keys break in VS Code Remote SSH terminal on Linux

I tried to reproduce this more narrowly on an Ubuntu 24.04 ARM64 VM with the desktop set to US International dead keys.

Tested:

• VS Code running locally on the Ubuntu VM
• VS Code Remote SSH from that Ubuntu VS Code instance back to ubuntu@127.0.0.1
• the patched branch
• the forced old path with CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=0
• stable Codex

Dead-key composition worked in both the local and Remote SSH VS Code terminals on that setup, so I still do not have evidence that all Linux VS Code terminals need the WSL workaround.

Could you share the exact failing setup:

• client OS/distro and desktop session on the Raspberry Pi
• keyboard layout/input source
• VS Code version/build
• whether CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex fixes it
• the output of echo "$TERM_PROGRAM"
• and, if possible, the raw bytes from a failing terminal with cat -v after pressing the dead-key sequence

If we can get one distinguishing detail from the failing Raspberry Pi path, we can target the fix instead of widening the current WSL-only workaround speculatively.

Thanks for investigating, @fcoury-oai. Here's the exact failing setup and what we discovered:

Exact Failing Setup

• Client: Windows 11 (native, not WSL) via Remote SSH
• Remote Host: Debian GNU/Linux Bookworm, aarch64 (Raspberry Pi)
• Kernel: 6.12.75+rpt-rpi-2712
• Keyboard Layout: French AZERTY with dead keys (circumflex ^, grave ` ``, etc.)
• VS Code: Latest (via Remote SSH shell integration)
• TERM_PROGRAM: vscode

The Problem

Dead keys didn't work in Codex CLI on this setup. Typing ^ o would leak escape sequences and produce just o instead of ô.

Root Cause

The keyboard_modes.rs code had this logic:

let is_vscode_terminal = is_wsl && running_in_vscode_terminal();

On a native Linux system (like this Debian Pi), is_wsl() returns false. So even though running_in_vscode_terminal() would correctly detect VSCode, the entire condition evaluated to false, leaving keyboard enhancement enabled.

With keyboard enhancement active in VSCode Remote SSH, the kitty protocol breaks dead key composition in the PTY forwarding through SSH.

The Fix (from PR #13638)

Removing the is_wsl && guard:

let is_vscode_terminal = running_in_vscode_terminal();

Now it correctly detects VSCode on any Linux system, not just WSL. When running in VSCode (with TERM_PROGRAM=vscode present), keyboard enhancement disables automatically, and dead keys compose correctly.

Confirmation

✅ With the patch: ^ o → ô (works correctly)
✅ TERM_PROGRAM=vscode is properly detected on Remote SSH
✅ No WSL involved — issue applies to any VSCode Remote SSH session to native Linux

Why Your Ubuntu Test Succeeded

On Ubuntu, the same detection would have worked if TERM_PROGRAM=vscode was set. The distinguishing detail is that the guard condition was the blocker, not the detection itself — it only worked on WSL, not on native Linux Remote SSH.

The patch broadens the fix to cover all VSCode terminal scenarios, not just WSL-specific ones.

---

Does this cover all the details you needed? Let me know if you need any additional information to validate the fix.