›_ Codex Issues
Codex Issues / #17770

Codex remains running after window close on Windows and cannot reopen UI until process is killed

Open 💬 6 comments Opened Apr 14, 2026 by MauGal
💡 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.409.20454

What subscription do you have?

Plus

What platform is your computer?

Windows 11

What issue are you seeing?

When I disable an MCP server and then close Codex, the app window disappears but the Codex process remains alive in Task Manager. If I try to launch Codex again from the Windows Start menu, no UI appears. The only way to reopen Codex is to manually terminate the remaining Codex process in Task Manager and then start it again.

This looks like a shutdown / single-instance / window restore problem in the Codex app.

What steps can reproduce the bug?

  1. Start Codex on Windows.
  2. Have multiple MCP servers configured. In my case, digitaliso and playwright are active.
  3. Open MCP settings.
  4. Disable the digitaliso MCP.
  5. Click the restart/reload button in MCP settings.
  6. Check Task Manager:
  • before disabling, there are multiple mcp_digitaliso processes
  • after disabling/restart, all mcp_digitaliso processes disappear correctly
  1. Close Codex normally.
  2. Observe that the Codex window disappears, but the Codex process remains active in Task Manager.
  3. Try launching Codex again from the Start menu.
  4. No UI appears.
  5. Manually terminate the remaining Codex process in Task Manager.
  6. Launch Codex again: the UI appears normally.

What is the expected behavior?

Codex should fully exit when closed, or reopen its existing window correctly on the next launch.

Additional information

  • The MCP processes for digitaliso do terminate correctly after disabling that MCP.
  • This makes it look less like an issue in the custom MCP itself, and more like a Codex app lifecycle issue after MCP changes.
  • I also have the Playwright MCP enabled, so this may involve interaction with multiple MCP servers rather than a single custom server.
  • On this machine, the issue is reproducible enough that the workaround is to manually kill the remaining Codex process every time.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #17675
  • #17322
  • #17205
  • #17476
  • #17411

Powered by Codex Action

JayCroghan · 3 months ago

Came here to report this same issue. I have no MCP servers, nothing but Codex naked. Anytime, everytime, I close Codex using the X in the corner, it remains running, the notification area icon remains but is unresponsive, and I have to kill the process(es) before I can open it again.

BenjaminHornung · 3 months ago

same here

PaulStSmith · 3 months ago

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

aekiori · 2 months ago

I've been seeing the same issue and was able to dig a bit deeper with ProcMon. Posting here in case it helps.

---

Symptoms

  • Tray icon right-click → Exit does not always fully terminate Codex
  • Multiple Codex.exe processes remain visible in Task Manager
  • Relaunching in that residual state produces a broken frame/shadow-only window (outer frame visible, inner renderer does not initialize)
  • Force-killing all Codex.exe processes restores normal startup

Possible trigger

Cannot reproduce reliably with light use. Seems much more likely after longer / heavier sessions.

ProcMon findings

Residual Codex.exe PIDs after tray Exit: 6036, 2304, 3332, 1420

These were not ghost entries — they kept emitting Process Profiling events, and were actively doing real work:

  • PID 1420: continued TCP/UDP traffic to host.docker.internal
  • PID 6036: continued file access/writes under C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_...

On relaunch:

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

The new process exits in ~0.66s with status 0 — looks like intentional handoff/attach to the existing instance rather than a crash.

Working theory

Codex appears to be single-instance and tries to attach to an already-running instance on relaunch. If that leftover instance is in a bad state, the UI comes back corrupted (frame/shadow only).

So the flow seems to be:

tray Exit
→ old processes not fully cleaned up
→ relaunch creates new process
→ new process hands off to leftover instance
→ leftover instance is in bad state
→ UI initializes as broken frame/shadow-only window
zakblacki · 2 months ago

I can confirm same behaviour on mac we have to close twice