Codex Windows App: tray Exit leaves residual processes; relaunch can return a broken frame/shadow-only window

Codex
1

Hi,

I think this is related to a few existing Windows Codex exit / relaunch reports, but I was able to dig a bit deeper into what seems to be happening.

Related issues

Those reports already suggest that Codex on Windows does not always exit cleanly.
In my case, I think I was able to narrow it down further with ProcMon.

Summary

Sometimes after right-clicking the Codex tray icon and choosing Exit, Codex does not fully terminate.
If I relaunch it in that residual state, the app can come back in a broken UI state — the outer window frame / shadow appears, but the inner renderer does not initialize properly.

Force-killing the remaining Codex.exe processes restores normal startup.

TL;DR

  • Tray Exit does not always terminate all Codex processes
  • Leftover Codex.exe processes can remain running in the background
  • Relaunch starts a new Codex.exe process that exits quickly with status 0
  • Control seems to hand off / attach to the leftover instance
  • If that leftover instance is already in a bad state, the UI returns as a broken frame/shadow-only window
  • Killing all Codex.exe processes fixes it

Symptoms

What I observed:

  • Right-click tray icon → Exit does not always fully terminate Codex
  • Multiple Codex.exe processes can remain visible in Task Manager
  • Relaunching Codex in that residual state can produce a broken frame/shadow-only window
  • Force-killing the remaining Codex.exe processes restores normal startup

Possible trigger

I cannot reproduce it reliably with very light use.
It seems much more likely after longer / heavier sessions.

My current working theory:

heavy / long session
→ incomplete tray Exit
→ residual processes remain
→ relaunch attaches to broken residual instance
→ UI comes back corrupted

ProcMon findings

I recorded one bad relaunch case with Process Monitor.

Residual processes remained alive after tray Exit

The following Codex.exe PIDs remained alive after Exit:

6036 / 2304 / 3332 / 1420

These were not ghost entries — they kept emitting Process Profiling events in ProcMon.

Residual processes were still doing real work

  • PID 1420 kept generating TCP/UDP traffic (host.docker.internal ...)
  • PID 6036 kept accessing and writing under C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_...

So this was not just “the UI is closed but stale process names remain.”
Actual background activity continued after Exit.

Relaunch started a new process that exited cleanly

2:01:48.3635698  Codex.exe 9536  Process Start
2:01:49.0226769  Codex.exe 9536  Process Exit  (Exit Status: 0)

The new process exited in about 0.66 seconds with status 0, so this does not look like an outright crash. It looks more like the app detected an existing instance and exited along its normal path.

Working theory

This looks like a single-instance / lifecycle bug.

Codex appears to try to reuse or attach to an already-running instance on relaunch.
The problem is that after some tray Exit cases, the old instance is not fully cleaned up.
If that residual instance is already in a bad state, the relaunched UI does not initialize properly and comes back as a broken frame/shadow-only window.

Compared to the earlier reports above, the additional things I was able to confirm:

  • The old processes really do remain alive after Exit
  • They continue doing real background work
  • Relaunch creates a new process, but that process exits normally instead of crashing
  • This makes it look more like a failed handoff / attach to a bad leftover instance

Question

Has anyone else seen this on Windows? Specifically:

  • Codex.exe processes remaining after tray Exit
  • Relaunch attaching to an existing instance instead of starting clean
  • Broken frame/shadow-only UI on relaunch
  • Higher repro rate after heavy / long sessions

If needed, I can also share screenshots and the relevant ProcMon excerpts.