[Windows][26.820.7780.0] Desktop launches suspended, leaks orphan codex.exe, fails to load/send threads, then silently relaunches

Summary

On Windows, Codex/ChatGPT Desktop package OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0 entered a multi-stage failure state during normal use:

1. After closing the app, it could not be reopened normally.
2. A newly activated ChatGPT.exe was created but remained permanently suspended: ~2.5 MB working set, 1 thread, MainWindowHandle=0, CPU=0, with ThreadState=Wait / WaitReason=Suspended.
3. Manually calling NtResumeProcess returned 0 and immediately restored the app to a normal Electron process tree (~338 MB, 64 threads, nonzero window handle).
4. The previous codex.exe app-server did not terminate. It remained as an orphan with a dead parent PID and only 1 thread, even after taskkill /F and Stop-Process -Force.
5. After recovery, an existing task/thread would not load its content. Later, messages would not submit and older tasks/chats would not load.
6. A full Windows restart did not resolve the thread/history/send failures.
7. The Desktop app then closed and reopened by itself. The old main ChatGPT.exe disappeared, but its codex.exe app-server again remained orphaned; a new main process and a new codex.exe app-server were created.
8. Windows Application Event Log contained no matching ChatGPT, Codex, or OpenAI crash event during the observed self-relaunch window.

This appears to be a Desktop lifecycle / activation / app-server cleanup / state-sync regression rather than a single stuck UI process.

Environment

• OS: Windows 11 x64
• Codex/ChatGPT Desktop MSIX package: 26.820.7780.0
• Package identity: OpenAI.Codex_2p2nqsd0c76g0
• Installed executable path: C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
• Bundled app-server path: C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\d0097be4feba73d0\codex.exe

Evidence: permanently suspended launch

Direct AppX activation succeeded in creating a process:

Start-Process explorer.exe -ArgumentList 'shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App'

But the resulting process was effectively uninitialized:

Id               : 12128
ProcessName      : ChatGPT
Responding       : True
MainWindowHandle : 0
Handles          : 0
Threads          : 1
CPU              : 0
WorkingSet       : 2588672

Thread state:

Id     ThreadState  WaitReason
33780  Wait         Suspended

The process command line was simply:

"C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"

Calling NtResumeProcess manually:

Add-Type @"
using System;
using System.Runtime.InteropServices;
public static class NativeMethods {
    [DllImport("ntdll.dll")]
    public static extern int NtResumeProcess(IntPtr ProcessHandle);
}
"@

$p = Get-Process -Id 12128
[NativeMethods]::NtResumeProcess($p.Handle)

returned:

0

Immediately afterward the same process became healthy:

Id               : 12128
CPU              : 16.609375
WorkingSet       : 337772544
Threads          : 64
MainWindowHandle : 396952

The Suspended wait reason disappeared and the full Electron child tree was spawned.

Evidence: orphaned app-server that cannot be cleaned up

Before the successful resume, an older app-server was left behind:

PID       : 27900
Name      : codex.exe
Parent PID: 28572
CPU       : 7.875 s
Threads   : 1

The parent process no longer existed.

Its command line showed the normal Desktop app-server invocation with the bundled codex_app MCP server and a per-instance named pipe.

Both of these failed to remove it:

taskkill /PID 27900 /T /F
Stop-Process -Id 27900 -Force

Stop-Process -Force returned without an error, but the same PID, CPU time, working set, handle count, and single thread remained visible afterward.

Its sole remaining thread was:

ThreadState: Wait
WaitReason : Executive

After the resumed ChatGPT.exe initialized normally, it created a new healthy app-server:

codex.exe PID 15380
Parent PID 12128
Threads 41

while orphan PID 27900 remained.

Evidence: thread/history/send failures

After the app was manually recovered:

• The Desktop shell rendered normally.
• An existing task/thread could be selected from the sidebar, but its conversation/task content remained blank and would not load.
• Later, messages would not submit.
• Older tasks/chats would not load.
• A full Windows restart did not resolve these failures.

This is similar to #40968 for prompt submission, but in this case it occurred together with suspended activation, orphan app-server leakage, thread/history loading failures, and later self-relaunch.

Evidence: silent self-relaunch and second orphan

Later, without the user intentionally closing the app, the main Desktop process changed.

The previous main process (ChatGPT.exe PID 12128) disappeared, leaving its app-server (codex.exe PID 15380) orphaned with one thread.

A completely new process tree then started:

15380  codex    26.08.2026 23:33:11.516  Threads=1   RAM=151.8 MB   # old orphan
35796  ChatGPT  26.08.2026 23:42:26.818  Threads=55  RAM=342.8 MB   # new main
5012   ChatGPT  26.08.2026 23:42:26.899  Threads=8   RAM=9.6 MB
14528  ChatGPT  26.08.2026 23:42:27.251  Threads=23  RAM=225.6 MB
29024  ChatGPT  26.08.2026 23:42:27.255  Threads=22  RAM=55.6 MB
24872  ChatGPT  26.08.2026 23:42:27.271  Threads=10  RAM=22.4 MB
5236   ChatGPT  26.08.2026 23:42:28.667  Threads=31  RAM=324.6 MB
35700  ChatGPT  26.08.2026 23:42:28.667  Threads=31  RAM=207.4 MB
22424  codex    26.08.2026 23:42:28.759  Threads=40  RAM=120.1 MB   # new active app-server
2268   ChatGPT  26.08.2026 23:42:33.141  Threads=35  RAM=261.3 MB
12992  ChatGPT  26.08.2026 23:42:33.142  Threads=12  RAM=35.0 MB

Process ancestry confirmed:

codex.exe 15380 -> parent 12128 (parent no longer exists)
ChatGPT.exe 35796 -> new main process
codex.exe 22424 -> parent 35796 (new healthy app-server)

The new Desktop tree therefore started while the previous app-server remained orphaned.

A query of the Windows Application event log for the previous 15 minutes returned no ChatGPT, Codex, or OpenAI matching crash/error event, so the visible close/reopen may have been an internal relaunch/self-recovery rather than a conventional WER-recorded crash.

Expected behavior

• AppX activation should resume the main ChatGPT.exe automatically; the user should never need to call NtResumeProcess manually.
• Closing/restarting/relaunching Desktop should terminate its codex.exe app-server and associated per-instance resources.
• A new Desktop instance should not leave previous app-server processes orphaned.
• Existing threads/tasks should reliably load after launch/restart.
• Prompt submission should either succeed or return a clear actionable error; it should not silently fail.
• If Desktop performs an internal recovery/relaunch, it should preserve thread state and cleanly tear down the previous process tree.

Related issues

• #38843 — permanently suspended ChatGPT.exe launch; NtResumeProcess workaround
• #40968 — Windows Desktop Send button/prompt submission failure on 26.820.7780.0
• #34614 — Windows child-process / orphan cleanup failures in Codex Desktop

The combination above reproduces on the current 26.820.7780.0 package and persisted even after a full Windows restart.

Start by reproducing the AppX activation path for ChatGPT.exe and observing the Electron process tree and bundled codex.exe app-server lifecycle described here. Compare the suspended launch, orphan cleanup, thread loading, prompt submission, and self-relaunch behavior with the expected behavior and related issues #38843, #40968, and #34614.