“Open in New Window” makes the selected chat disappear

Open 💬 2 comments Opened Jul 24, 2026 by fribbis

💡 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.721.31836

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

While using ChatGPT mode, I pressed Command-K to search for an existing conversation. I selected the conversation, and it opened in a small panel near the bottom-right corner of the application.
I then clicked “Open in New Window.” The chat panel disappeared, but the conversation did not open in a separate window.
I checked the macOS Window menu, and no additional window was listed.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f9305-ef44-7d51-a85f-1bcd76d5977c

What is the expected behavior?

The selected conversation opens in a separate application window.

Additional information

The chat panel disappears, but no new window is created. Only the main ChatGPT window appears in the Window menu.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#34906

Powered by Codex Action

rio-builds · 29 days ago

Adding another macOS data point with local diagnostic evidence.

Environment

ChatGPT Desktop / Codex: 26.721.81911 (build 5973)
macOS 26.5.2 (25F84), Apple Silicon

Reproduction coverage

The failure is consistent in all of these cases:

Start a new Quick Chat, exchange messages, then click Open in a new window.
Resume a historical chat in Quick Chat, continue the conversation, then click the button.
Open a historical chat directly and click the button.

In every case, the Quick Chat popover closes immediately and no visible window appears. There is no user-facing error.

Local diagnostic evidence

The desktop main-process log confirms that multiple auxiliary windows with appearance=quickChat were actually created. They remained rendererWindowVisible=false and rendererWindowFocused=false for their entire lifetime.

For two clean reproductions, the interval from the auxiliary window finishing its main-frame load to the IPC connection reset was approximately:

15.014 seconds
15.007 seconds

This matches the packaged client's 15-second Quick Chat prewarm readiness timeout. The packaged flow creates a hidden prewarmed Quick Chat window, waits for its renderer-ready handshake, and only calls show() / focus() after readiness and the target conversation route are confirmed. If readiness is not confirmed, the hidden window is closed. Meanwhile, the source popover is dismissed immediately after invoking the open request, without waiting for successful presentation or rolling back on failure.

A related renderer warning was also recorded during Quick Chat interaction:

Matched leaf route at location "/" does not have an element or Component ... resulting in an "empty" page.

The immediate failure point therefore appears to be between successful creation of the hidden quickChat auxiliary window and completion of its ready/route handshake. It is not a minimized or off-screen window, and it is not limited to conversations without a server ID.

Ideally, the source popover should close only after the auxiliary window is visible, and the client should restore the popover or show an error when the readiness handshake times out.