[Windows][Codex Desktop] Agent can terminate its own host by force-killing ChatGPT renderer processes during IAB recovery

What version of the Codex App are you using (From “About Codex” dialog)?

• Windows MSIX package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Bundled Browser release observed in the task: 26.727.51351
• ChatGPT.exe file version: 150.0.7871.182

What subscription do you have?

Not included; this appears independent of account tier.

What platform is your computer?

Windows 11 x64, version 10.0.26200.

What issue are you seeing?

While performing local Web QA with the Codex in-app Browser (IAB), an agent recovered from a timed-out browser navigation by enumerating ChatGPT.exe --type=renderer processes and force-killing the three newest renderers. Those processes were all children of the installed Codex/ChatGPT Desktop package.

The agent labeled them “QA renderers”, but process name, --type=renderer, creation time, and working set do not distinguish an IAB-controlled page from Codex's own UI/host renderers. About three seconds after the shell command, the entire Codex AppX container was destroyed and every app-owned task stopped.

This is an agent process-identity / tool-safety failure rather than an unexplained native crash: the terminating shell command is present in the task transcript immediately before the app disappears.

Sanitized command sequence:

Get-CimInstance Win32_Process |
    Where-Object {
        $_.Name -eq "ChatGPT.exe" -and
        $_.CommandLine -match "--type=renderer"
    }

Stop-Process -Id <three-newest-renderer-pids> -Force -ErrorAction Stop

Observed timeline (UTC+08:00):

• 10:26:53 — IAB Page.navigate timed out.
• 10:27:12 — the agent enumerated all package-owned ChatGPT.exe --type=renderer processes.
• 10:27:22.343 — the agent invoked Stop-Process -Force on the three newest renderer PIDs.
• The tool call never produced a persisted tool result.
• 10:27:24 — the old Codex app-server log stopped abruptly.
• 10:27:25.303 — Windows AppModel-Runtime Event 217 recorded destruction of the complete OpenAI.Codex desktop AppX container.
• 10:53:14 — the user manually relaunched Codex; a completely new process tree was created.

Negative evidence at the failure boundary:

• no Windows Application Error, Application Hang, .NET Runtime, or WER report;
• no Crashpad report or dump;
• no Codex fatal, panic, OOM, shutdown, or relaunch entry;
• no resource-exhaustion, GPU reset, power, Defender, or package-update event;
• the package update had completed roughly 15.5 hours earlier.

The Chromium profile records the previous exit as Crashed.

What steps can reproduce the bug?

I do not recommend intentionally repeating the final process-kill step on a normal workstation.

The observed path was:

1. Use Codex Desktop's IAB for local Web QA.
2. Open a new IAB tab and encounter a CDP/navigation timeout.
3. Instead of treating the stale tab as recoverable or abandoning it, let the agent escalate to OS process inspection.
4. Identify “QA” processes using only ChatGPT.exe --type=renderer, creation time, and working set.
5. Force-stop the selected renderer PIDs.
6. Observe the whole Codex Desktop process tree exit and the active task remain interrupted.

This was observed once and was not deliberately repeated because it is destructive, but the transcript-to-AppX timing is precise.

What is the expected behavior?

• Codex should never infer IAB tab ownership from the shared ChatGPT.exe --type=renderer process identity.
• Browser recovery should use scoped IAB/tab lifecycle APIs, rebind a stale tab, or leave the tab open; it should not fall back to killing package-owned renderer processes.
• Tool safety should protect the current Codex/ChatGPT host process tree—including renderer, GPU, utility, browser helper, and app-server children—from Stop-Process, taskkill, or equivalent commands unless the user explicitly requests host termination and the impact is confirmed.
• If a child renderer is terminated unexpectedly, the desktop shell should recover it or present an error instead of silently taking down the complete AppX container.
• A destructive host-targeting tool call should require a postcondition/impact gate and should not be described as ordinary browser cleanup.

Additional information

This appears related but not duplicate to:

• #34239 — IAB tab/WebView teardown can terminate Codex on Windows;
• #35210 — browser.tabs.finalize() can terminate the app through the supported IAB lifecycle;
• #32321 — a macOS agent-created launchctl job repeatedly terminated its own ChatGPT host.

Those reports involve native IAB teardown or a macOS restart scheduler. This report's distinct trigger is the agent directly force-killing indistinguishable package-owned ChatGPT.exe renderer processes after an IAB timeout.

Opaque identifiers for OpenAI-side correlation:

• thread/session: 019fad20-7141-7302-b8a4-a69691284942
• turn: 019fc03c-fdec-7251-8704-a4cde32f44f2
• tool call: call_2mars4EFJpCvKSFq7y4I0PLQ

Raw transcripts and logs are not attached publicly because they contain local paths and conversation metadata. Targeted sanitized excerpts can be provided if maintainers request them.