Bug: Enter key used to confirm Japanese IME composition submits answer in Plan Mode

Reproducing this in the VS Code extension as well (the original report is about the desktop app, but the behavior is identical — likely the same chat composer component).

Environment

• Codex VS Code extension (openai.chatgpt): 26.417.40842-darwin-arm64
• VS Code: 1.116.0 (arm64)
• macOS: 15.7.3 (build 24G419, Apple Silicon)
• IME: Google Japanese Input (Google 日本語入力)

Repro

1. Open the Codex chat panel in VS Code and enter Plan Mode.
2. When Codex asks a question, start typing a Japanese answer, e.g. てすと.
3. Press Space to convert to テスト, then press Enter to commit the IME candidate.
4. The answer is submitted immediately, even though the Enter was intended only to finalize IME composition.

Frequency

Always (100% reproducible with Google Japanese Input on macOS).

Likely cause

The keydown handler on the composer appears to treat Enter as submit without checking event.isComposing (or event.keyCode === 229). The standard fix is to bail out early while composition is active:

if (e.key === 'Enter' && (e.isComposing || e.keyCode === 229)) return;

This is a very common oversight in web-based chat inputs and affects every IME that uses Enter to confirm conversion (Japanese, Chinese, Korean).

Same here. Reproduces with Japanese IME. This makes Plan Mode free-form answers hard to use because Enter is used to confirm IME conversion, but Codex also treats it as submitting the answer.

Since the Desktop / VS Code UI source is not public, external contributors cannot submit a PR directly.

OS: macOS 26.4 (Build 25E246)
App: Codex Desktop 26.513.20950
IME: Japanese IME

I can reproduce what looks like the same bug in Codex Desktop.

Environment:

• Codex Desktop: 26.519.81530, app build 3178
• macOS: 26.4, build 25E246
• Input method: Japanese IME

Behavior:

• In Plan Mode, while entering Japanese text, pressing Enter to confirm an IME conversion also advances/submits the current Plan Mode question.
• Expected behavior: Enter while IME composition is active should only confirm the conversion and should not submit/advance the question.
• Additional symptom: the composed text sometimes remains in the next Plan Mode question input, which may indicate that the input state is not reset cleanly when the question changes.

Implementation suspicion:

• The Plan Mode answer input likely needs to ignore Enter when composition is active, for example by checking event.isComposing, event.nativeEvent?.isComposing, and/or event.keyCode === 229.
• The input value may also need to be keyed or reset by the current elicitation/question id.

Local logs do not capture key event state, but the behavior is consistently reproducible with Japanese IME composition confirmation.

I’d like to work on a focused fix for this, if the Codex team is open to an external PR for this issue.

Reproduction environment

I can reproduce the issue when answering a request_user_input / Plan Mode question with Japanese IME enabled. Pressing Enter to confirm IME composition is treated as submitting or advancing the answer.

This matches the behavior reported above:

• Japanese IME / CJK IME composition active
• Plan Mode or request_user_input question UI focused
• Enter is used to confirm the IME candidate
• The UI handles the same Enter as submit/next

Root cause hypothesis

The request_user_input answer UI appears to reuse the TUI ChatComposer, but its submit handling likely does not distinguish IME composition Enter from an intentional submit Enter.

In particular, the overlay submit path seems to treat the configured composer submit key as submit/next without checking whether the key event is part of IME composition.

The likely area is:

• codex-rs/tui/src/bottom_pane/request_user_input/mod.rs
• shared composer input handling in codex-rs/tui/src/bottom_pane/chat_composer*

Proposed scope

I’d keep the PR narrowly scoped to the request_user_input / Plan Mode question UI behavior:

• Do not change general chat submit behavior unless the same helper already owns the relevant logic.
• Do not change the request_user_input protocol or app-server API.
• Do not change default keybindings.
• Only prevent Enter from submitting/advancing while IME composition is active.

Proposed approach

Add an IME-composition guard in the relevant Enter/submit handling path, so Enter during composition is allowed to confirm the IME candidate and is not interpreted as submit/next.

If the existing event type exposes composition state, use that directly. If not, I’ll first trace where composition state is represented in the TUI input stack and keep the fix local to the composer/overlay boundary.

Test plan

I plan to add regression coverage for the request_user_input overlay / composer path so that:

• Enter normally still submits or advances the question.
• Enter while IME composition is active does not submit or advance.
• Existing request_user_input snapshot coverage remains stable unless the expected UI behavior intentionally changes.

Would the Codex team be open to an invited PR for this narrow fix?