›_ Codex Issues
Codex Issues / #32688

App Server TUI accumulates already-processed messages under “Messages to be submitted after next tool call”

Open 💬 0 comments Opened Jul 13, 2026 by emilfihlman

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 7.0.10+deb14-amd64 x86_64 unknown

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

GNU Screen 5.0.1, TERM=screen-256color-bce

What issue are you seeing?

The App Server TUI pending-message list can become an accumulating history of messages that Codex has already received and acted on.

The UI currently shows:

Messages to be submitted after next tool call
  ↳ Did you get my feedback or was it lost? I accidentally pressed ctrl+d
  ↳ And remember, no legacy or compatibility is needed.
  ↳ And remember to not overbuild or overengineer

All three messages have already been processed:

  • The first message was recorded at 2026-07-12 17:52:00 UTC. Codex answered it at 17:52:11, and that turn completed.
  • Codex explicitly acknowledged the second message at 2026-07-13 03:06:00 UTC.
  • Codex explicitly acknowledged the third message at 03:06:09 UTC.

Despite this, the banner still lists all three as waiting to be submitted. It survives subsequent tool calls, agent waits, completed turns, and both Working and Ready states.

The UI also says Esc will “interrupt and send immediately,” even though these messages have already been acted on. This makes it impossible to know whether Esc will clear the stale state, send something new, or duplicate an already-processed instruction.

Thread ID: 019f5453-0e12-7ca3-bbee-6a780824156d

What steps can reproduce the bug?

The initial state corruption is intermittent:

  1. Start a turn that remains active across tool calls or agent waits.
  2. Submit a follow-up/steering message while the turn is active.
  3. In the original occurrence, Ctrl+D was pressed accidentally around this point. It is not confirmed whether Ctrl+D is causal.
  4. Let Codex receive and answer the message.
  5. While Codex is still working, submit more steering messages.
  6. Observe that Codex receives and responds to each message, but each one is also appended to Messages to be submitted after next tool call.
  7. Continue through more tool calls or allow the turn to finish.
  8. Observe that the already-processed messages remain in the pending list.

What is the expected behavior?

The pending-message list should contain only messages that have not yet been delivered.

As soon as a message is committed or consumed:

  • it should be removed from the pending preview;
  • it should not remain after the turn becomes Ready;
  • the UI should not advertise Esc as a way to submit it again.

Additional information

The stale state was verified in both the live GNU Screen session and the corresponding rollout log. This is not merely delayed rendering: the rollout contains the user messages and the assistant acknowledgements while the TUI simultaneously retains those messages in its pending list.

I have also observed a variant where a queued message appears never to submit. Pressing Esc sometimes promotes it, but that behavior is not reliably reproducible.

Related but not exact duplicates:

View original on GitHub ↗