Repository navigation
Windows: App does not fully exit on window close (X) + UI hit-testing issue in sidebar ("New Chat") #17322
Description
Environment:
- OS: Windows 11 x64
- Codex Desktop Version: 26.406.3494.0
- Installation type: Standard Windows installer
- CLI: Codex CLI works нормально (no issues)
Summary:
There are two related issues in the Windows desktop app:
- Closing the application via the window close button (X) does not terminate the app completely — multiple background processes remain running, preventing relaunch.
- UI hit-testing is broken in the sidebar: hover and click behavior on the "New Chat" button is inconsistent and appears to pass through the element.
Issue 1: App does not exit when clicking "X"
Steps to reproduce:
- Launch Codex desktop app
- Click the window close button (X) in the top-right corner
Expected behavior:
Application fully terminates (all processes exit)
Actual behavior:
- The window closes
- ~5–6 Codex processes remain running in Task Manager
- Relaunching Codex fails (no window appears)
Workaround:
- Using
File → Exitproperly terminates all processes - Alternatively, manually killing processes (
taskkill /IM codex.exe /F) allows relaunch
Notes:
This suggests that the window close event does not trigger full application shutdown (app.quit() not called or not propagated).
Issue 2: Sidebar UI interaction bug ("New Chat")
Steps to reproduce:
- Open Codex app
- Move mouse over "New Chat" button in the sidebar
Expected behavior:
- Hover state activates
- Click triggers new chat
Actual behavior:
- Hover state does not activate consistently
- Click sometimes behaves as if it targets the window behind the UI
- Double-click behaves like interacting with the window title bar (not the button)
Additional observations:
- Behavior resembles broken hit-testing or incorrect input layer mapping
- Feels like pointer events are not correctly bound to the UI element
Regression
This behavior did not occur ~1 week ago.
The issue appeared after an update (current version: 26.406.3494.0).
Additional observations
- Issue 1 and Issue 2 may be related (renderer / event loop / Electron lifecycle inconsistency)
- Previous UI glitches (hover issues) were observed before the shutdown problem appeared
- Codex CLI works correctly → issue isolated to desktop runtime (Electron layer)
Impact
- Prevents normal app usage (cannot reliably restart app)
- Requires manual process cleanup
- UI interaction becomes unreliable
Suggested areas to investigate
- Handling of
BrowserWindowclose event app.on('window-all-closed')behavior on Windows- Renderer hit-testing / pointer events
- GPU / compositing layer issues (optional: test with
--disable-gpu)
Activity
github-actions commentedon Apr 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Apr 10, 2026
Thanks for the report. These seem like unrelated issues. In the future, please file one bug report per issue.
accendium commentedon Apr 11, 2026
Any updates on this? Really frustrating there isn't a clear way to modify the closing behavior so that it doesn't minimize to tray on close. Most apps on windows have this, and I always turn it off because apps shouldn't hide themselves when closed, they should just close. Am I missing a setting that exists?
argifford commentedon Apr 13, 2026
I am experiencing Issue 1 after app upgrade to version Codex app for Windows 26.409.20454
I can reproduce this consistently.
Additional detail from my setup:
Closing the app with the titlebar X leaves Codex backend/helper processes running.
Using File -> Exit shuts down cleanly.
The leftover processes on my machine are typically:
codex.exe / codex (app-server)
uvx.exe (MCP helpers)
node.exe (MCP helper)
In my case, this happens with MCP servers configured, including uvx-backed Atlassian servers and a node-backed Outlook server.
After closing with X, a cleanup script finds about 5 leftover Codex-related processes; after File -> Exit, it does not.
This makes it look like the window-close path is not triggering the same full shutdown flow as File -> Exit.
If useful, I can provide exact process examples and a minimal config description.
Vathivis commentedon Apr 14, 2026
I'm experiencing both issues, since the last two updates I think. The New Chat button doesn't work, it doesn't highlight on hover and clicking it does nothing
7761camelextraneous commentedon Apr 14, 2026
I experience both these issues as well. They make it difficult to use Codex and I am trying other products as a result. Are fixes forthcoming, please?
thomak-dev commentedon Apr 15, 2026
How can the "New chat" button be broken in a Release version of a paid AI app? Like, isn't this the only button that matters?
RuslanSemchenko commentedon Apr 16, 2026
same problem
Sahil170595 commentedon Apr 16, 2026
Same symptom here, and this issue looks like the right match.
What I’m seeing:
New chatbutton does not respond when clickedCtrl+Nstill successfully creates a new chatThat makes this look more like a sidebar UI click / hit-testing problem than a failure of the underlying new-chat action.
Screenshot/context: this is the left sidebar
New chatcontrol at the very top, not the other new-thread controls elsewhere in the app.PaulStSmith commentedon Apr 17, 2026
Apparently, the issue has been fixed on 26.415.20818
I just tested and both “New chat”, close/reopen are working as they should, and right-clicking the tray icon closes it completely.
However, “New chat” creates a new chat for the current project, not a totally new one. But this is the standard behavior when opening Codex, if defaults to the last opened project.
gabrieleguetta commentedon Apr 18, 2026
Issue 1 still persists
linhui73110 commentedon Apr 19, 2026
I can reproduce a closely related variant of this on Windows with the installed app.
Additional findings from repeated local testing:
The problem is not only "close button (X) leaves processes behind".
On my system, even tray "Exit" can sometimes leave 4 headless Codex.exe processes running.
The strongest trigger appears to be the hotkey / floating window path.
In logs, the app creates:
Disabling the Alt+P hotkey in settings significantly improves shutdown reliability.
After disabling that hotkey, I was able to complete multiple launch -> tray -> Exit cycles without leftover processes.
However, disabling Alt+P is not a full fix.
Clicking the tray icon itself can still trigger the floating hotkey-style window path, and after that, tray Exit may again leave 4 background processes behind.
Tray menu actions seem to behave differently:
The floating window is not a normal window:
This makes it look more like a palette / quick access window than a normal BrowserWindow, and it may not be getting destroyed cleanly.
This looks like an upstream Windows desktop lifecycle / tray / hotkeyWindow issue.
Based on the behavior and logs, the most suspicious area seems to be any code path that creates hotkeyWindowHome / hotkeyWindowThread, especially when triggered from the tray icon.
linhui73110 commentedon Apr 19, 2026
From more repeated testing on Windows, I think the floating window path is the key predictor of whether residual background processes will be left behind.
More specifically:
So at least on my system, the issue seems less like a generic close failure and more like:
This is still based on repeated local repro, not a source-level confirmation.
But if you are narrowing the bug down, I would focus on the lifecycle of the floating window / hotkey window path first.
linhui73110 commentedon Apr 19, 2026
Further narrowing from repeated Windows installed-app testing:
I no longer think this is specific to Alt+P itself.
What I can now reproduce is:
I also changed the hotkey from Alt+P to Ctrl+Alt+Shift+P and repeated the test.
That still left 4 residual processes after tray Exit.
So the current evidence points more to the hotkey feature / hotkey initialization path itself, not specifically the Alt+P key combination.
Current strongest working theory:
In short: the key variable seems to be whether the hotkey feature is enabled at startup, not which shortcut is assigned.
kristof-toth-wuerth-hu commentedon Apr 29, 2026
For me with the latest update the New Chat button works
rodalpho commentedon May 4, 2026
I also find issue 1 (closing the window with the X button does not close the Codex app, it remains in the system tray) extremely annoying. This behavior should be configurable in the application.
scott8 commentedon Jun 4, 2026
I am consistently seeing Issues 1 also. Background tasks, typically 8 of them, do not go away when the UI is closed with the X. When will this be put on the roadmap? This needs to be fixed. This is not standard behavior for a Windows application.
FieldMarshallVague commentedon Jun 25, 2026
So frustrating. This is obviously by design. And it is highly suspicious behavior. It is unacceptable to prevent closing of an app when choosing 'X'. At the very least, a 'close to tray' option in settings is expected and off by default. Their intent is to hope you forget to close it so they can monitor and do what they want in the background (and, it seems ignore all PRs that try to introduce this behavior).
No chance this gets changed, so I'm not using this app. Adobe-levels of cringe.
aimansour commentedon Jul 20, 2026
This still affects Codex Desktop client 26.715.52143 / Windows package 26.715.7063.0 on Microsoft Windows NT 10.0.19045.0 x64.
A particularly disruptive case is skill management:
Failed.Windows background-app permission is already disabled for this application, but the application still keeps its processes running after the window is closed.
Please add an explicit setting such as “Keep running in background when the window is closed”, default it appropriately for Windows, and provide an accessible Quit action that reliably terminates the main app, app-server, plugin/skill watchers, MCP helpers, tray/hotkey windows, and other child processes. Closing the window should honor that setting so users can perform a genuine restart without using Task Manager.
dfa1234 commentedon Sep 14, 2026
Please add a Windows setting to choose what happens when clicking the window close button (X): “Quit application” or “Minimize to system tray”.
I want closing the window to fully quit Codex. Currently, I cannot find a setting to disable the minimize-to-tray behavior.
Offering this choice is a widely established convention in Windows applications that support minimizing to the system tray. Users should not be forced to use the tray menu just to quit an application. This is the first application I have personally encountered that imposes this behavior without an option to change it.
Please make this configurable so users can choose the behavior that fits their workflow.
rodalpho commentedon Sep 14, 2026
You would think AI would be easily able to add this simple feature to help seriously annoyed users. But I guess not.
downloaderfan commentedon Sep 18, 2026
I too wish to remove ChatGPT completely from system tray in Windows as it serves no purpose to me & just makes properly closing ChatGPT harder.
At least, there needs to option, like how it's main competitor provides one.