Popup window stays above macOS IME candidate window while typing

Resolved 💬 2 comments Opened Mar 23, 2026 by SamsurTee Closed Jul 5, 2026

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

Version 26.318.11754 (1100)

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.x arm64

What issue are you seeing?

When a thread is opened in a popup window on macOS and I type with a Chinese IME, the popup window appears to stay above the macOS candidate window / candidate selection UI.

In practice, the IME candidate bar is visually covered or competes with the popup window while typing, which makes candidate selection awkward.

This seems related to the recent popup regression discussed in #15162, where popup windows are now also limited to a single window instead of allowing multiple independent popup windows.

What steps can reproduce the bug?

  1. Open any thread in "Open in Popup Window".
  2. Focus the input box inside the popup window.
  3. Switch to a Chinese IME.
  4. Type text that triggers the IME candidate window.
  5. Observe that the popup window stays visually above the candidate UI.

What is the expected behavior?

The macOS IME candidate window should appear above the app UI as usual, or the popup window should not be created with an always-on-top / panel-style window policy that interferes with IME candidate selection.

Additional information

I also left a related note on #15162 here:
https://github.com/openai/codex/issues/15162#issuecomment-4108108340

From inspecting the installed app bundle locally, this looks consistent with the popup action being routed through a different windowing path:

  • The bundle still contains a singleton hotkey-window-controller path with threadWindow, threadWindowPromise, and lastDetailRoute, which matches the multi-window regression in #15162.
  • The same bundle also marks hotkeyWindowThread with alwaysOnTop: true on macOS and uses type: panel, which looks consistent with the IME candidate-window overlap behavior.
  • There is also a separate threadOverlayManager path with open-thread-overlay and thread-overlay-set-always-on-top, suggesting the explicit popup action may now be using the hotkey/panel path instead of the older per-thread overlay path.

So this may be the same regression chain manifesting in two ways:

  • popup windows can no longer be opened multiple times
  • popup windows now stay above IME candidate UI on macOS

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗