TUI: Enter can be downgraded to "Queued follow-up inputs" during a long-running goal until restart

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

ChatGPT subscription (the exact tier is not exposed by the CLI in this environment)

Which model were you using?

gpt-5.6-sol, xhigh reasoning effort

What platform is your computer?

Linux 4.12.14-120-default x86_64 x86_64

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

xterm-256color over SSH, inside tmux 3.7b

Codex doctor report

Sanitized summary:

{
  "version": "0.147.0",
  "platform": "linux-x86_64",
  "runtime": "standalone",
  "install": "consistent",
  "config": "loaded",
  "auth": "configured",
  "state_databases": "healthy",
  "websocket": "connected (HTTP 101 Switching Protocols)",
  "notes": [
    "optional MCP configuration issues",
    "some rollout files missing from the state DB",
    "one HTTP reachability check failed, although the active goal continued streaming and running tools"
  ]
}

Paths, thread IDs, and host-specific details were removed.

What issue are you seeing?

During a long-running /goal turn, pressing Enter on a follow-up message can incorrectly place it under:

Queued follow-up inputs
  ↳ <message>
    shift + ← edit last queued message

The expected Enter behavior during an active turn is the pending-steer path:

Messages to be submitted after next tool call
(press esc to interrupt and send immediately)

Tab is supposed to create a queued follow-up. In the broken state, Enter behaves semantically like Tab.

The queued message remains local and is not added to the rollout or message history, even after multiple tool-call boundaries. Exiting the entire TUI with Ctrl+C and starting Codex again clears the problem.

This is not a terminal key translation issue:

• a live strace at the tmux server's PTY read point captured the physical key packet as 0x0d (carriage return / Enter), not 0x09 (Tab)
• there were no tmux Enter/Tab remappings
• [tui.keymap] had no custom bindings
• the built-in keymap is Enter = submit and Tab = queue

What steps can reproduce the bug?

This was observed in a long-lived TUI process and has not yet been reduced to a deterministic fresh-session reproducer:

1. Start Codex CLI in tmux.
2. Start a long-running /goal.
3. Let the goal run through many model/tool boundaries.
4. In the observed session, collaboration/settings selections had also changed (Plan → Default, then reasoning effort to xhigh) before the failure. This may be a contributing trigger.
5. While the goal is actively running, type a normal follow-up such as report progress percentage.
6. Press Enter.
7. Observe that the message appears under Queued follow-up inputs instead of Messages to be submitted after next tool call.
8. Let several tool calls complete. The message remains queued and does not enter the rollout.
9. Exit the entire TUI with Ctrl+C and restart Codex. Enter resumes the expected behavior.

A useful diagnostic distinction is that the terminal really delivers Enter (0x0d); the conversion to a queued follow-up happens inside the TUI.

What is the expected behavior?

While an agent turn is active:

• Enter should create a pending steer and display Messages to be submitted after next tool call.
• Tab should create Queued follow-up inputs.
• A stale TUI state flag should not silently downgrade Enter to a queued next-turn message.
• If immediate steering is temporarily unavailable, the UI should explain why rather than presenting Enter and Tab as equivalent.
• Restarting the TUI should not be required to restore Enter behavior.

Additional information

This looks distinct from:

• #15842, where a message correctly enters the pending-steer UI but becomes stuck there
• #37974, where queued follow-ups are stranded after a failed prompt-edit branch

In this case the initial classification itself is wrong: a real Enter submission is placed directly into Queued follow-up inputs.

Based on local code inspection, a possible path is a stale submission-suppression state (for example suppress_queue_autosend) after a settings/modal transition. InputResult::Submitted can then fail the should_submit_now check and fall through to queue_user_message, producing exactly the observed UI. This is an inference, not a confirmed internal-state dump.

The same TUI process had successfully handled an earlier Enter steer, and no code path should re-enable startup queue_submissions after the session is configured. The failure appeared later in the long-running goal and disappeared only after restarting the TUI.