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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #15842

Powered by Codex Action

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?

Hey @etraut-openai, it's not working in IntelliJ's terminal. I tried on the default terminal, and it is working as expected.

This sounds like it might be a configuration issue or bug in the IntelliJ's terminal app.

I saw a related UX symptom on Codex CLI 0.137.0: while a tool call is running, the TUI displays Messages 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”.

This looks like a queued-user-message transition boundary, not only a TUI keybinding bug.

The runtime should separate:

user message is queued behind a running tool call
≠
user message has been promoted into the active turn

If the UI says:

"press Esc to interrupt and send immediately"

then Esc should produce an explicit transition:

queued_user_message
+
interrupt_requested
=>
current tool-call continuation cancelled or paused
+
queued message promoted to active input

Minimal invariant:

EscInterruptSupported(queue_state, tool_state)
=>
the queued user message must either be promoted, or the runtime must emit a named diagnostic explaining why promotion is unsupported.

Failure shape:

tool call is running
+
user types a follow-up message
+
UI says the message will be submitted after next tool call
+
user presses Esc to interrupt and send immediately
+
nothing happens
+
tool-call state continues unchanged
=>
the advertised interrupt transition is not supported by the runtime state machine

A useful local classifier:

def classify_queued_message_interrupt(queue_state, tool_state, key_event):
if key_event != "Esc":
return {
"decision": "no_interrupt",
"reason": "non_interrupt_key",
}

if not queue_state.get("queued_user_message"):
return {
"decision": "no_interrupt",
"reason": "no_queued_message",
}

if tool_state["state"] in {"RUNNING", "AWAITING_RESULT"}:
return {
"decision": "interrupt_tool_and_promote_message",
"queued_message_id": queue_state["queued_user_message"]["id"],
"tool_state": tool_state["state"],
}

return {
"decision": "promote_message",
"queued_message_id": queue_state["queued_user_message"]["id"],
}

Regression cases:

1. no queued message + Esc

=> no-op with no queued-message state change

1. queued message + no running tool call + Esc

=> promote queued message immediately

1. queued message + running tool call + Esc

=> interrupt or pause current tool continuation and promote queued message

1. queued message + tool call cannot be interrupted

=> visible diagnostic: queued_message_interrupt_unsupported

1. queued message remains pending after Esc

=> UI must not claim "send immediately"

1. interrupted tool later returns a result

=> result is recorded as interrupted/stale, not as continuation authority for the old turn

The key boundary is:

a queued user message is not active input until the runtime performs a supported promotion transition.

If Esc is advertised as the promotion trigger, it should either execute that transition or fail visibly with a named diagnostic, not silently leave the session in the same tool-call state.