Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix Shift+Enter in Plan mode questions UI inserts newline but also advances to the next question [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#23448•Fetched 2026-05-20 03:49:58
View on GitHub
Comments
0
Participants
1
Timeline
9
Reactions
0
Author
iamkanguk97iamkanguk97
Participants
iamkanguk97iamkanguk97
Timeline (top)
labeled ×4closed ×1cross-referenced ×1referenced ×1

Root Cause

While using Codex CLI in Plan mode, I was answering a structured question in the questions UI. I used Tab to focus the free-form answer field, typed some text, and pressed Shift+Enter because I expected it to insert a newline while staying on the same question page.

Fix Action

Fixed

PR fix notes

PR #23536: fix(tui): preserve modified enter in plan questions

Description (problem / solution / changelog)

Why

Plan mode questionnaires reuse the shared composer for free-form answers, but the surrounding request_user_input overlay still treated every KeyCode::Enter as “advance to the next question.” That made Shift+Enter insert a newline in the composer and then immediately advance the questionnaire anyway.

Fixes #23448.

What Changed

  • pass the live RuntimeKeymap into RequestUserInputOverlay so its embedded composer honors existing /keymap composer/editor remaps
  • advance free-form questions only on the configured composer submit binding, instead of any Enter-shaped key event
  • add regressions for Shift+Enter newline behavior and configured composer submit bindings inside the questionnaire UI

How to Test

  1. Start Codex in Plan mode and trigger a request_user_input questionnaire with a free-form answer field.
  2. Focus the free-form field, type a line, then press Shift+Enter.
  3. Confirm the answer gains a newline and the questionnaire stays on the same question.
  4. Press the configured submit binding, or plain Enter with the default keymap, and confirm the questionnaire advances as before.

Targeted tests:

  • cargo test -p codex-tui bottom_pane::request_user_input::tests::freeform_ -- --nocapture

Notes

  • cargo test -p codex-tui still reaches an unrelated existing stack overflow in app::tests::discard_side_thread_removes_agent_navigation_entry on this checkout.
  • just argument-comment-lint is locally blocked by Bazel analysis failing in external compiler-rt before the lint runs.

Changed files

  • codex-rs/tui/src/bottom_pane/mod.rs (modified, +1/-1)
  • codex-rs/tui/src/bottom_pane/request_user_input/mod.rs (modified, +171/-23)
  • codex-rs/tui/src/bottom_pane/request_user_input/snapshots/codex_tui__bottom_pane__request_user_input__tests__request_user_input_freeform_remapped_submit.snap (added, +13/-0)
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.131.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Warp

Codex doctor report

What issue are you seeing?

While using Codex CLI in Plan mode, I was answering a structured question in the questions UI. I used Tab to focus the free-form answer field, typed some text, and pressed Shift+Enter because I expected it to insert a newline while staying on the same question page.

Instead, Codex immediately advanced to the next question/page. If I pressed Esc to go back to the previous page, the newline had actually been inserted into the answer.

So the free-form text input appears to handle Shift+Enter as newline insertion, but the Plan mode questions UI also appears to handle the same key event as “next” / page navigation.

What steps can reproduce the bug?

  1. Start Codex CLI.
  2. Enter Plan mode.
  3. Trigger a flow where Codex asks structured questions using the questions UI.
  4. Navigate to a question that has a free-form answer field.
  5. Press Tab until the free-form text input is focused.
  6. Type a first line of text.
  7. Press Shift+Enter.
  8. Observe that Codex advances to the next question/page.
  9. Press Esc to return to the previous page.
  10. Observe that the previous answer now contains the newline, even though the UI also advanced.

What is the expected behavior?

When the free-form answer field is focused, Shift+Enter should insert a newline and remain on the current question page.

If plain Enter is intended to advance to the next question, Shift+Enter should be consumed by the focused text input and should not also trigger page navigation.

Additional information

Related issues, but not exact duplicates:

  • #4218: normal TUI prompt sends/submits instead of inserting newline.
  • #20501 / #20580 / #21115: normal composer newline keybinding regressions.
  • #8673: feature request for Shift+Enter newline support in the interactive prompt.

This report is specifically about the Plan mode structured questions / request_user_input UI and the double-handling behavior: newline insertion plus page advance.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt issue#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - ✅(Solved) Fix Shift+Enter in Plan mode questions UI inserts newline but also advances to the next question [1 pull requests, 1 participants]