Codex TUI inserts a space for Super+Space XKB layout-switch chord

Start with codex-rs/tui/src/bottom_pane/chat_composer.rs, then compare its modifier handling with codex-rs/tui/src/bottom_pane/textarea.rs and codex-rs/tui/src/key_hint.rs. Add or run a composer regression test for a SUPER-modified Space and verify that the Super+Space chord changes the layout without inserting text after the paste-burst timeout.

Environment

• Codex CLI: 0.145.0
• Model: gpt-5.6-sol (the behavior occurs in local TUI input handling and appears model-independent)
• Subscription: not disclosed; not relevant to local TUI input handling
• Platform: Arch Linux, kernel 7.1.4-arch1-1, x86_64
• Desktop/session: Hyprland 0.56.0, Wayland
• Terminal: Ghostty 1.3.1-arch2, no multiplexer
• Keyboard configuration: XKB layouts us,ru with option grp:win_space_toggle

Issue

Pressing Super+Space switches the keyboard layout as expected, but it also inserts a literal space into the Codex composer. Other terminal applications tested honor the complete Super+Space chord and do not treat it as an ordinary Space press.

Reproduction

1. Configure XKB with layouts us,ru and option grp:win_space_toggle.
2. Open Ghostty in a Wayland/Hyprland session.
3. Start codex and focus the composer.
4. Press Super+Space.
5. Observe that the keyboard layout changes and a space appears in the composer.

Expected behavior

The keyboard layout changes and the composer remains unchanged.

Actual behavior

The keyboard layout changes and Codex inserts one literal space.

Source-level analysis

This appears to be an unintended interaction between Kitty keyboard reporting and paste-burst detection:

• Codex enables DISAMBIGUATE_ESCAPE_CODES | REPORT_EVENT_TYPES | REPORT_ALTERNATE_KEYS: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/tui/keyboard_modes.rs#L126-L133
• With those flags, the Ghostty 1.3.1 VT encoder emits ESC[32;9u for a non-text Super+Space event (Space plus the SUPER modifier). The same event emits no bytes in legacy mode.
• has_ctrl_or_alt checks CONTROL and ALT but not SUPER: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/key_hint.rs#L201-L202
• The composer consequently admits Char events with SUPER into paste-burst detection: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/bottom_pane/chat_composer.rs#L3464-L3480
• When the burst timeout expires, the held character is inserted as a string, dropping its modifiers: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/bottom_pane/chat_composer.rs#L3405-L3413
• The text area itself only inserts characters carrying no modifier or SHIFT, so a SUPER-modified character would otherwise be ignored: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/bottom_pane/textarea.rs#L618-L633

The same Ctrl/Alt-only condition is present on main as of 2026-07-27. I could not find an existing issue describing this behavior.

A likely regression test would send a Space character with KeyModifiers::SUPER through the composer and assert that it neither enters paste-burst handling nor inserts text after the timeout. The likely fix is to share the text-producing modifier predicate used by the text area, while preserving intended AltGr behavior.

Troubleshooting notes

• The keymap parser currently supports Ctrl, Alt, and Shift but not Super, so /keymap does not provide a configuration workaround: https://github.com/openai/codex/blob/rust-v0.145.0/codex-rs/tui/src/keymap_setup.rs#L713-L724
• An invocation-only diagnostic, codex -c disable_paste_burst=true, is predicted from the source path to avoid the insertion, but has not yet been independently confirmed.
• A full codex doctor --json dump is omitted because it was run inside the Codex investigation sandbox, where proxy/network failures are expected and misleading. The relevant version, platform, session, and terminal details are included above.