Codex Desktop: ESC from CJK IME composition passes through and interrupts the model

Clarification to avoid a possible misunderstanding:

This is not a request to disable Esc globally whenever the composer input has focus.

The distinction is between two different user intents that currently appear to collapse into one event path:

1. IME intent: while a CJK IME is actively composing text or showing a candidate/composition state, Esc means cancel/close the IME composition or candidate selection.
2. Codex intent: when no IME composition is active, Esc may reasonably mean interrupt/stop the current Codex model response.

The bug is that case 1 appears to leak through and also triggers case 2. So the requested behavior is specifically: if the key event belongs to an active IME composition lifecycle, Codex Desktop should treat it as consumed by text input/IME handling and should not also run the app-level interrupt handler.

A useful regression test would be: start a running model response, focus the composer, activate a CJK IME, begin composition, press Esc to cancel the composition, and verify that the model response is not interrupted. Then repeat with no active IME composition and verify normal Esc interrupt behavior still works.

One more observation that may help narrow the regression:

This feels like it may have started after the Esc interrupt behavior became broader or more aggressively captured at the app level. In other words, the interrupt handler may now be attached closer to a global/window/document shortcut path, or may be running during the capture phase, instead of only handling Esc events that remain after text input and IME composition handling.

That would explain why an Esc keypress intended only to cancel an active CJK IME composition now also cancels the Codex task. So the likely boundary to inspect is the app-level keyboard shortcut / interrupt handler and whether it respects active IME composition state before triggering stop/interruption.

Additional CJK/IME context:

This may be easy to miss if testing is mostly done with Latin keyboard input. In CJK input methods, Esc is not only an application-level cancel key; it is also part of the normal IME composition lifecycle.

For example, users often press Esc to cancel an uncommitted Pinyin/Kana/Hangul composition or close a candidate/composition state, while still intending the surrounding app task to continue. That text has not necessarily been committed to the input field yet, so the user intent is limited to the IME layer.

So the important distinction is not just "input focused vs not focused". The relevant boundary is:

• active IME composition/candidate state: Esc belongs to the text input / IME lifecycle and should not interrupt Codex
• no active IME composition: Esc can keep the normal Codex interrupt behavior

This is why the current behavior is particularly disruptive for CJK users: a routine IME correction/cancel action can unexpectedly stop a long-running Codex task.

这真的是个大问题，只要是有习惯在codex工作时继续输入文字，就一定会遇到这个问题，很妨碍高频使用者，合理怀疑目前大部分用户是等待返回再继续输入的……

之前可以在热键设置里把decline request的快捷键（ecs）删除来解决这个问题，但是现在停止当前任务和decline request解绑了，导致之前的解法也无用了。

感谢提问者的qoli/codex-disable-escape-tweak项目，我让codex自己把它安装上了，问题完美解决，感谢！

下面是由gemini翻译的英语，Below is the English translation by Gemini.

This is truly a major issue. Anyone who is used to continuing to type while Codex is processing will definitely run into this problem. It is a huge hindrance for heavy users, and I reasonably suspect that most users currently just wait for the response to return before they continue typing...

Previously, you could solve this by removing the "decline request" shortcut (Esc) in the hotkey settings. However, stopping the current task has now been uncoupled from "decline request," making the old workaround useless.

Thanks to the original poster for the qoli/codex-disable-escape-tweak project. I had Codex install it itself, and the problem is perfectly resolved. Thank you!