Final Korean character is inserted into next pending input after option 3 in command approval modal
Resolved 💬 5 comments Opened Feb 20, 2026 by fabric0de Closed Apr 24, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.217.1959(669)
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
This happens in the command approval modal that shows:
1) Yes
2) Yes, and don't ask again...
3) No, and tell Codex what to do differently
When I choose option 3, type Korean text, and submit, one final Korean character is inserted into the next pending input line.
What steps can reproduce the bug?
Steps to reproduce
- Open the command approval modal.
- Select option 3: No, and tell Codex what to do differently.
- Type Korean text (example:
근데 그게 뭐지). - Submit.
- After the modal closes, check the next pending input line.
Actual behavior
The final Korean character is inserted into the next pending input line (for example, 지 from 근데 그게 뭐지).
Expected behavior
No character should be carried over after submitting option 3.
The next pending input line should remain empty unless I type new input.
Test results (manual repeated runs)
- Korean input: reproduced consistently.
- English input (
what is that): did not reproduce. - Numeric-only input: did not reproduce.
- Reproduced on the same modal + option 3 path repeatedly.
What is the expected behavior?
This appears specific to Korean character input/composition handling, rather than a generic text submission issue.
Additional information
- Reproduces with Korean input.
- Did not reproduce with English input in my tests.
- Using mouse click on Submit did not reproduce; this mainly happens on Enter submit.
- The entered sentence itself is submitted correctly; only an extra trailing Hangul character leaks into the next pending input line.
5 Comments
Adding a follow-up since this issue is still untriaged.
Current impact in daily use:
Why I suspect this is the cause:
This pattern strongly suggests an IME composition commit timing/order issue on the Enter submit path (modal close + focus transition).
Screenshots
<img width="615" height="199" alt="Image" src="https://github.com/user-attachments/assets/c77bd1dc-2c7d-4094-a280-fa7500cbea79" />
<img width="616" height="247" alt="Image" src="https://github.com/user-attachments/assets/af1ce504-70b8-4e42-b4f3-b074b8a80c40" />
Which terminal emulator are you using? Is it the standard Mac "Terminal" program? Have you tried to repro this with other terminals?
I think your analysis is on point. The interaction between IMEs and terminals can be complicated and timing-sensitive. I suspect that the IME is injecting the final character in a way that it arrives after the Enter. Fixing issues like this without introducing regressions can be tricky.
I use Warp terminal emulator.
As you mentioned, this looks like a timing-sensitive and tricky issue.
To improve fix accuracy and reduce regression risk, I’ll update the issue with stronger reproducibility data and clearer hypotheses (input method, submit method, and environment matrix).
Version 26.228.1430 (760)
Mac
I also occasionally hit this issue.
This no longer reproduces on the latest Codex App, so I’ll close this issue for now.