Sending a message near the end of a codex response does not queue it

What version of Codex CLI is running?

0.106.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

Ghostty

What issue are you seeing?

When the model is working on a task and nearing the end of it, as seen in the below screenshot:, the next queued message (the first "also, ...") is never sent to codex. The second one, is sent as seen by the model responding.

<img width="1576" height="731" alt="Image" src="https://github.com/user-attachments/assets/b03e758a-b73b-4e5b-8ba6-bad62dd8eeb0" />

Here's the text version of the above image ^^:

 Good call. I tuned defaults to reduce robotic sound:

  - Default EN voice: en-US-ChristopherNeural (instead of Guy)
  - Default prosody: --edge-rate +0% and --edge-pitch +0Hz (neutral)
  - Default chunk size: --max-chars-per-chunk 1000 (fewer voice resets)


• I’m committing the voice naturalness tuning changes now.

• Ran git add apps/audiobook/src/audiobook/config.py apps/audiobook/src/audiobook/cli.py apps/audiobook/README.rst && git commit -m "audiobook: tune default edge voice for less robotic narration"
  └ [sdko/audiobook-epub-mp4 8bf76232] audiobook: tune default edge voice for less robotic narration
     3 files changed, 7 insertions(+), 7 deletions(-)


› also is there a better audio format? 5 chunks are 3.3mb


• Committed.

  - 8bf76232 audiobook: tune default edge voice for less robotic narration


› also is there a better audio format? 5 chunks are 3.3mb


• Yes. 3.3 MB for 5 chunks is normal for temporary chunk files, but you can get much smaller finals.

  Best options:

  - Most compatible: AAC mono at 32k–48k (.m4a/.m4b or audio track in .mp4)
  - Smallest for speech: Opus at 20k–32k (.opus/.webm), but less universal compatibility

  Right now your pipeline is likely bigger than needed because it goes through WAV and uses a higher AAC bitrate.
  For audiobooks, a good default is:

  - -ac 1 (mono)
  - -ar 22050
  - -b:a 48k (or 32k if you want smaller)

  If you want, I can patch it so output defaults to compact audiobook settings and add flags like --audio-bitrate / --audio-codec.

What steps can reproduce the bug?

I don't have a consistent repro, but here's the thread id: 019ca174-4777-7a43-b122-4febcc984fb9

What is the expected behavior?

The latest message is queued as it normally does

Additional information

_No response_