Sending a message near the end of a codex response does not queue it #13078
Description
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.
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