Windows desktop app loses composer focus and breaks Chinese IME input during thread switching

Resolved 💬 2 comments Opened Jun 25, 2026 by safge Closed Jun 27, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.71553

What subscription do you have?

pro20x

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 (x64)

What issue are you seeing?

The Codex Desktop composer intermittently loses input focus while typing.

Symptoms:

I can type normally at first, then halfway through input the composer stops accepting input.
I must click the composer again before I can continue typing.
When this happens during Chinese input, the IME/input mode appears to disappear.
After clicking the composer again, Chinese input often does not recover.
In those cases I must switch out of Codex and then switch back to Codex before Chinese IME works again.

At first I thought this only happened in newly created threads, but I later confirmed it also happens in existing threads.

This appears to be more than a simple editor focus issue. During local investigation I observed Codex Desktop window-level blur/focus events around the same time, together with repeated internal browser/sidebar lifecycle events.

Relevant local evidence included:

window.blur
window.focus
app.browser-window-blur
app.browser-window-focus
repeated IAB_LIFECYCLE received browser sidebar owner sync
repeated browser-session-registry rebinding messages

This makes me suspect a desktop focus-management bug, possibly involving embedded browser/sidebar/IAB routing, rather than a pure IME-only problem.

What steps can reproduce the bug?

I cannot guarantee a 100% deterministic repro, but this pattern happens repeatedly:

Open Codex Desktop on Windows.
Open an existing thread or create a new thread.
Click the composer and start typing in Chinese.
Switch between threads a few times and continue typing.
Eventually the composer loses input state:

input stops,
I need to click again,
Chinese IME may disappear and not recover until I switch out of the app and back.

Expected behavior:

Composer focus should remain stable while typing.
Switching threads should not cause the desktop window or composer to lose input focus unexpectedly.
Chinese IME should continue working without needing to click the composer again or alt-tab away and back.

Additional local notes:

ctfmon.exe, TabTip.exe, and TextInputHost.exe were still running when this happened.
This does not look like a normal Windows IME process crash on my machine.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#28872
#28929

Powered by Codex Action

safge · 2 months ago

Thanks — I reviewed the suggested duplicates.

#28872 looks closely related and may be the same underlying desktop focus bug.
#28929 also looks related, but it is more specific to macOS / Chinese IME / Pet activation and is already closed as a duplicate.

My case is on Windows, and in addition to composer focus loss it also disrupts Chinese IME input:

the composer can stop accepting input mid-typing
I have to click the composer again
Chinese IME may not recover until I switch out of Codex and back
thread switching appears to make it easier to trigger

During local investigation I also observed:

window.blur
window.focus
app.browser-window-blur
repeated IAB_LIFECYCLE received browser sidebar owner sync
repeated browser-session-registry rebinding messages

So this may be the same underlying bug family as #28872, but I am leaving this issue open for now because the Windows + IME behavior and local evidence may still be useful unless maintainers prefer to consolidate it.