BUG: Codex for Windows does not fully exit; old process tree remains alive after app close / Where can I report it?

[jimmybeam3000]

Short summary:
Codex for Windows does not always terminate cleanly when the app window is closed. After closing the app, parts of the previous Codex process tree can remain alive in the background, especially powershell.exe and conhost.exe child processes started by Codex. Launching Codex again can then create a second full Codex instance while the old one is still running. I attached a process-monitor log with timestamps, parent/child relationships, and the overlapping old/new process trees.

Product:
Codex for Windows desktop app

Environment:

• OS: Windows
• App package path observed in process command lines:
  C:\Program Files\WindowsApps\OpenAI.Codex_26.311.2262.0_x64__2p2nqsd0c76g0\app\Codex.exe
• User data dir observed:
  C:\Users\xxxxxx\AppData\Roaming\Codex
• Date observed: 2026-03-15
• Locale observed: German (de)

Summary:
When closing Codex on Windows, the app does not always terminate cleanly. A previous Codex instance can remain alive in the background, including child terminal-related processes such as powershell.exe and conhost.exe. Starting Codex again can create a second full Codex process tree while the old one is still running.

Impact:

• Multiple Codex instances remain active simultaneously after closing and reopening the app
• Background CPU/RAM usage remains allocated
• Terminal/console child processes remain running
• User may need to manually kill processes in Task Manager
• The app can appear closed while resources are still in use

Reproducibility:
Observed multiple times

Steps to reproduce:

1. Kill all existing Codex processes in Task Manager to start from a clean state.
2. Start a PowerShell monitor script that tracks Codex.exe, codex.exe, powershell.exe, conhost.exe, and related child processes.
3. Launch Codex.
4. Open a new thread and send a message.
5. Open the integrated terminal in Codex and use it at least once.
6. Close Codex normally via the window close action.
7. Wait 30-60 seconds without manually killing any process.
8. Launch Codex again.
9. Observe processes in Task Manager and in the attached monitor log.

Expected result:
Closing Codex should terminate the full process tree for that session, including:

• main Codex.exe process
• renderer / gpu / utility / app-server child processes
• terminal-related child processes such as powershell.exe and conhost.exe

Actual result:
After closing Codex, the previous session may remain partially or fully alive. On relaunch, a second Codex instance starts while processes from the prior instance are still present.

Evidence from attached log:
The attached process-monitor log shows that an older Codex session remained alive when a newer session started.

Relevant findings:

• At 2026-03-15 19:08:55 a Codex session starts with main process:
  Codex.exe PID 26964 PPID 8452

• Child processes associated with that session include:
  Codex.exe PID 22180 PPID 26964
  Codex.exe PID 24116 PPID 26964
  Codex.exe PID 27000 PPID 26964
  powershell.exe PID 28076 PPID 26964
  powershell.exe PID 19484 PPID 26964
  conhost.exe PID 6912 PPID 26964
  conhost.exe PID 10848 PPID 26964

• Later, at 2026-03-15 19:11:35, another Codex session starts with main process:
  Codex.exe PID 3840 PPID 8452

• Child processes associated with the newer session include:
  Codex.exe PID 6456 PPID 3840
  Codex.exe PID 7688 PPID 3840
  Codex.exe PID 8792 PPID 3840
  Codex.exe PID 18744 PPID 3840
  codex.exe PID 20116 PPID 3840
  powershell.exe PID 27148 PPID 3840
  conhost.exe PID 16252 PPID 3840

• At 2026-03-15 19:12:00 both sessions are still present at the same time:
  Older session still alive:
  Codex.exe 26964
  Codex.exe 22180
  Codex.exe 24116
  Codex.exe 27000
  powershell.exe 28076
  powershell.exe 19484
  conhost.exe 6912
  conhost.exe 10848

  Newer session also alive:
  Codex.exe 3840
  Codex.exe 6456
  Codex.exe 7688
  Codex.exe 8792
  Codex.exe 18744
  codex.exe 20116
  powershell.exe 27148
  conhost.exe 16252

Observed behavior suggests:

• the previous Codex session did not fully shut down
• terminal child processes may be preventing clean exit or are not being terminated on shutdown
• relaunch does not ensure old background processes are gone before starting a new process tree

Notes:

• During investigation, a bug in my custom PowerShell monitor script caused “The variable 'pid' cannot be overwritten” messages. That is a script issue, not the Codex issue.
• The Codex process-leak conclusion is based on the process tree, parent/child relationships, timestamps, and overlapping old/new sessions.

Attachment:

• codex-monitor-diff.log

Request:
Please investigate Codex shutdown behavior on Windows, especially cleanup of:

• integrated terminal child processes
• app-server / renderer / utility child processes
• full process-tree termination on app close

[etraut-openai]

This is a discussion forum. If you'd like to report a bug, please use the issue tracker in this project. I think this is a known issue, so do a search before opening a new bug report.

[jimmybeam3000]

ok, shall I delete it?

[aekiori]

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