Repository navigation
Messages to be submitted after next tool call (press esc to interrupt and send immediately) not working on CLI #17095
Description
What version of Codex CLI is running?
codex-cli 0.118.0
What subscription do you have?
Enterprise
Which model were you using?
gpt-5.4
What platform is your computer?
Darwin 25.4.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
No response
What issue are you seeing?
Messages to be submitted after next tool call (press esc to interrupt and send immediately) not working on CLI
What steps can reproduce the bug?
Steps to reproduce
- Open the CLI.
- Submit a prompt that triggers a long-running tool call.
- While the tool call is still running, type a follow-up message into the input box.
- Wait for the UI hint: Messages to be submitted after next tool call (press esc to interrupt and send immediately).
- Press Esc.
Nothing happens. The queued message is not sent immediately, and the CLI stays in the current tool-call state.
What is the expected behavior?
The queued message should be submitted immediately after pressing Esc, interrupting the current tool call.
Additional information
No response
Activity
github-actions commentedon Apr 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Apr 8, 2026
I'm not able to repro this problem.
Which terminal emulator are you using? Perhaps it is configured to ignore the esc or map it to some other action?
JaySabva commentedon Apr 8, 2026
Hey @etraut-openai, it's not working in IntelliJ's terminal. I tried on the default terminal, and it is working as expected.
etraut-openai commentedon Apr 8, 2026
This sounds like it might be a configuration issue or bug in the IntelliJ's terminal app.
Yoon-Jeong-ho commentedon Jun 8, 2026
I saw a related UX symptom on Codex CLI
0.137.0: while a tool call is running, the TUI displaysMessages to be submitted after next tool call...above the normal composer. To a user typing during output, this can look like two input areas, where only the lower one is the normal active composer.This seems distinct from a tmux HUD/viewport issue I also found locally, but the queued-follow-up composer label/placement is what made the user report it as “two typing boxes”.
explcre commentedon Aug 3, 2026
I am also experiencing this problem.
Environment:
codex-cli 0.145.0SSH terminal019fc4df-715d-7e52-b466-f70a94eee9aaWhile Codex is working or running a tool, I often type a correction or additional instruction. Pressing
Escafter the message indicating that it can interrupt and send immediately does not consistently interrupt the current activity or incorporate the queued instruction promptly.The desired behavior is:
Escimmediately interrupts or pauses the current tool call when possible.Claude Code currently feels more responsive for mid-task steering and corrections. Improving this interaction would make long Codex CLI sessions much easier to control.