TUI drops/garbles accented (dead-key) characters when pty is relayed over websocket (code-server / browser terminal), works fine in local terminal

Description

Typing accented / composed (dead-key) characters (e.g. á, ã, ç — Brazilian Portuguese ABNT2 layout) in the interactive TUI prompt silently drops the accent (or garbles the character) only when Codex is running inside a terminal whose pty is relayed over a network/websocket (code-server's browser-based integrated terminal, built on xterm.js / VS Code's terminal stack). The exact same keyboard input works correctly when Codex is run in a native local terminal (SSH session) on the same host.

Environment

• Codex CLI: 0.144.1 (npm install, @openai/codex)
• Install: npm global, Node v24.14.1
• OS: Ubuntu 24.04.4 LTS (x86_64)
• Broken environment: code-server 4.117.0 integrated terminal (xterm.js), TERM=xterm-256color, TERM_PROGRAM=vscode, LANG=en_US.UTF-8
• Working environment: native SSH terminal on the same host, TERM=xterm-256color, LANG=C.UTF-8
• bubblewrap (bwrap) installed, sandbox reports healthy in codex doctor

Isolation performed

To rule out a locale/browser/VS Code-wide issue before filing, I compared behavior of three programs inside the same code-server terminal tab:

| Program | Accented input in code-server terminal |
|---|---|
| plain bash prompt | ✅ works |
| Claude Code CLI (claude) interactive prompt | ✅ works |
| Codex CLI (codex) interactive prompt | ❌ accent dropped/garbled |
| Codex CLI (codex) in a native local terminal, same host | ✅ works |

This rules out: locale (LANG/LC_* are UTF-8 in both environments and effectively equivalent), the browser/OS keyboard layout itself (works for two other programs in the identical tab), and TERM settings (identical value in both). The failure is specific to Codex's TUI input handling when stdin arrives via a websocket-relayed pty rather than a local pty.

Hypothesis

Accented characters typed via a dead-key sequence resolve to a multi-byte UTF-8 sequence (e.g. á = 0xC3 0xA1). Over a local pty, these bytes are normally delivered to the reading process in one atomic read(). Over a websocket-relayed pty (code-server/xterm.js, and likely also affects VS Code Remote-SSH / other browser-based or containerized dev environments), the two bytes can plausibly arrive across separate read/poll events. If Codex's raw-mode input reader does not buffer partial multi-byte UTF-8 sequences across reads, this would explain the dropped/garbled character — while Claude Code's TUI apparently does handle this correctly in the same conditions.

I don't have access to Codex's TUI input-handling source to confirm this at the code level, but the isolation above narrows it down to Codex-specific input decoding under fragmented/chunked stdin delivery, not environment/locale/keyboard-layout.

Workarounds found

• codex exec "prompt with acentuação" (non-interactive) — prompt is passed as an already-composed CLI argument, sidesteps the interactive reader entirely.
• Typing in a native/local terminal instead of a browser-relayed one.

Related (not exact duplicates)

• #4994 (closed) — international keyboard support
• #6385 (closed) — Windows TUI paste loses Turkish characters (different platform/trigger — paste vs. live dead-key typing — but same broad category: TUI mishandling non-ASCII multi-byte input)

Happy to provide more diagnostics (asciinema recording, strace of the codex process, etc.) if useful.