"Open in Popup Window" now replaces the existing popup instead of opening multiple windows

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

• #14467

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate.检测到可能重复的问题。请核实并关闭您的问题。 * Open in popup stopped working in latest update #14467 _Powered by Codex Action由 Codex Action 提供支持_

This is not a duplicate of #14467.

The issue described in #14467 is about "Open in popup stopped working", where the popup functionality does not work at all.

In contrast, my issue is about a regression in behavior:

• "Open in Popup Window" still works
• However, it no longer allows multiple popup windows for different threads
• Instead, it reuses/replaces the existing popup window

Key differences:

• #14467: popup does not open / broken functionality
• This issue: popup works, but multi-window capability is lost

Additionally, this change started specifically after the March 19, 2026 update, and represents a behavioral regression rather than a complete failure.

Please consider keeping this issue open as it describes a different problem affecting multitasking workflows.

I did a local investigation on the macOS app bundle for Codex App 26.317.21539 (build 1088) on March 19, 2026.

This looks like a regression in which the explicit “Open in Popup Window” action is now going through a different windowing path than before.

What I found:

• There appear to be two separate implementations for this feature in the desktop app.
• One path is a thread overlay manager that is keyed by hostId + conversationId, which supports one popup per thread.
• The other path is a hotkey/popout window controller that is singleton by design. It maintains a single threadWindow, threadWindowPromise, and lastDetailRoute, and its ensureThreadWindow() method reuses the existing thread window if one already exists.

Why this matches the bug:

• If the app uses the thread overlay path, multiple popup windows can coexist for different threads.
• If the app uses the hotkey/popout path, opening a second thread will reuse the existing popup window and navigate it to the new thread instead of creating a second window.
• That singleton behavior matches the regression exactly.

Additional detail:

• The UI appears to use the same “Open in Popout Window” label for both code paths.
• Based on the installed app bundle, the renderer now seems to prefer the hotkey/popout route when that feature is available, and only falls back to the multi-window thread overlay route otherwise.
• So the regression is likely not a thread ID collision. It looks more like a routing/feature-selection regression: the menu action is hitting the singleton popout implementation instead of the multi-window thread overlay implementation.

Likely fix direction:

• Route the explicit “Open in Popup Window” action back to the thread-overlay implementation, or
• Update the hotkey/popout implementation to support multiple thread windows keyed by conversation/thread ID.

I could not verify the original source repo for the desktop shell itself from the public repo, so this is based on inspection of the installed Electron app bundle. But the evidence strongly points to the popup action being routed to the singleton hotkey window path in build 1088.

I am seeing the exact same behaviour after the latest update Version 26.318.11754 (1100) on macos. Unable to open multiple popout windows which i was able to do before the update. Also, behaviour matches with the popout being replaced and only 1 popout window is allowed. Additionally working on multiple threads just keeps one thread on a thinking status while the other one progresses properly, and only after quitting and reopening the app it shows the thread already finished working.

I am seeing the exact same behaviour after the latest update Version 26.318.11754 (1100) on macos. Unable to open multiple popout windows which i was able to do before the update. Also, behaviour matches with the popout being replaced and only 1 popout window is allowed. Additionally working on multiple threads just keeps one thread on a thinking status while the other one progresses properly, and only after quitting and reopening the app it shows the thread already finished working.

This feature was extremely useful and significantly improved productivity. Being able to open multiple popup windows allowed working across different threads in parallel without constantly switching context.

With the latest update limiting it to a single popup window, it essentially removes the core value of this feature. It now behaves more like a temporary viewer rather than a true multi-window workflow tool.

Would really appreciate restoring the ability to open multiple independent popup windows, as it was a key part of an efficient workflow.

yeah right now having to switch between threads on one codex window is very inconvenient. Hope this gets fixed faster.

encountering the same issue.
Another problem related to popout (I feel it's related) is:
When follow up a request after the popout task finished, it's likely showing errors message "Error creating task
no-client-found". and,

1. This error message appears both in the popout window and the orignal window
2. Closing the popput window does not fix the issue
3. If you reboot Codex app, it works.

Test environment:
MacOS: 15.6.1 (24G90)
Codex Desktop App: Version 26.318.11754 (1100)

Please help resolve it.

I am also seeing a second regression around the same popup/popup-window path on macOS, likely related to the same windowing change.

Environment:

• Codex App 26.318.11754 (1100)
• macOS 15.x
• Chinese IME / candidate window active while typing in a popup window

Observed behavior:

• The popup window appears to stay above the macOS IME candidate bar / candidate selection UI while typing.
• This makes candidate selection awkward because the popup window visually covers or competes with the candidate UI.
• Separately, the popup can no longer be opened multiple times for different threads, which matches the core issue in this ticket.

Why this may be related:

• In the installed app bundle, the single-window hotkey-window-controller path still contains a singleton threadWindow / threadWindowPromise / lastDetailRoute, which matches the multi-window regression described here.
• The same bundle also marks hotkeyWindowThread with alwaysOnTop: true on macOS (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, which suggests the explicit popup action may now be routed through the hotkey/panel path instead of the older per-thread overlay path.

If useful, I can open a dedicated issue for the IME candidate-window overlap, but I wanted to link it here first because it looks like part of the same regression chain.

I updated the Codex after hearing that a new plugin had been added, and now I’m experiencing the same issue.

It used to be convenient to open multiple pop-ups and work on several tasks at once, but now that the functionality has been downgraded, it’s frustrating.

I’m also seeing this on the Windows app.

Before the update, I could open multiple pop-out windows for different threads at the same time.
After the update, I am seeing both of these regressions:

• opening a second "Open in Popout Window" replaces the existing popout instead of opening a new one
• only one popout window can exist at a time
• the popout window is no longer resizable
• before this update, resizing worked normally for me

This was still working for me on March 28, 2026, and it started failing after the update I received on March 30, 2026.

Platform:

• Windows
• Codex app version: [26.325.31654]

This also seems related to #16180, since I am seeing both the single-popout regression and the non-resizable window behavior together.

This also seems related to #16180, since I am seeing both the single-popout regression and the non-resizable window behavior together.

I opened the issue. Seeing the same problem.

Really hope we get to have the app open source soon so we can locally fork and revert/fix this for ourselves instead of waiting for a fix.

现在4.1号，我尝试了下载codex1.03，可以同时多打开几个app来达成多开的效果 https://github.com/Haleclipse/CodexDesktop-Rebuild/releases

<img width="670" height="113" alt="Image" src="https://github.com/user-attachments/assets/165b7646-2508-4902-8aaf-f43a21d3919c" />

This bug is still persistent in Version 1.2026.63.11 (a543e92118e)

It's a massive limitation to productivity.

Agreed

Agreed. Exponentially limiting productivity.

Noticing further regression. No longer able to pop out specific chat. Pop out shortcut is now just a new chat window.

Severe eye strain from constantly having to re-scroll rapidly through chat logs.