Windows: App does not fully exit on window close (X) + UI hit-testing issue in sidebar ("New Chat")

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

• #17205
• #16540
• #15949
• #17244
• #16678

Powered by Codex Action

Thanks for the report. These seem like unrelated issues. In the future, please file one bug report per issue.

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?

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.

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

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?

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?

same problem

Same symptom here, and this issue looks like the right match.

What I’m seeing:

• the top-left sidebar New chat button does not respond when clicked
• Ctrl+N still successfully creates a new chat

That 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 chat control at the very top, not the other new-thread controls elsewhere in the app.

<img width="352" height="163" alt="Image" src="https://github.com/user-attachments/assets/40d4c7ee-9d70-4e02-b9f6-b665696c6c3b" />

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.

Issue 1 still persists

I can reproduce a closely related variant of this on Windows with the installed app.

Additional findings from repeated local testing:

1. 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.

1. The strongest trigger appears to be the hotkey / floating window path.

In logs, the app creates:

• appearance=hotkeyWindowHome
• appearance=hotkeyWindowThread

1. 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.

1. 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.

1. Tray menu actions seem to behave differently:

• "Open Codex" appears to be safe
• "New Chat" appears to be safe
• single-clicking the tray icon is the risky path

1. The floating window is not a normal window:

• no standard close button
• it disappears when focus is lost

This makes it look more like a palette / quick access window than a normal BrowserWindow, and it may not be getting destroyed cleanly.

1. 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.

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:

• when the app stays on the normal main-window path, shutdown is usually clean
• once the floating / hotkey-style window appears, the chance of leftover headless Codex.exe processes goes up a lot

So at least on my system, the issue seems less like a generic close failure and more like:

• floating window appears
• that window path does not tear down cleanly
• tray Exit or later shutdown then leaves residual processes behind

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.

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:

• if the hotkey feature is already enabled before app startup, tray Exit can still leave 4 residual Codex.exe processes behind
• this can happen even if I never press the hotkey and never intentionally open the floating window
• if the hotkey feature is disabled before startup, the same launch -> tray -> Exit path shuts down cleanly on my machine

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:

• enabling the hotkey before startup is enough to put the app on the risky lifecycle path
• actually pressing the hotkey or visibly seeing the floating window is not required every time
• disabling the hotkey only after startup is not equivalent to starting with it disabled

In short: the key variable seems to be whether the hotkey feature is enabled at startup, not which shortcut is assigned.

For me with the latest update the New Chat button works

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.

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.

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.

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:

1. Installing or removing a skill sometimes reports Failed.
2. I close the Codex window and reopen it to perform a clean restart.
3. The app has remained alive in the background, so reopening does not produce a clean process restart and the stale state can persist.
4. I must manually terminate the remaining Codex/ChatGPT processes in Task Manager before reopening the app.

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.