[Windows][26.727.4816.0] Codex Security workspace enters renderer respawn loop and leaks memory

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

OpenAI.Codex 26.727.4816.0 (x64); Codex Security plugin 0.1.15

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Opening the native Codex Security workspace causes the task view to crash or reload repeatedly. The main Desktop process and the backend security scan remain alive, but the host continuously creates new ChatGPT.exe --type=renderer processes without disposing the previous renderers.

Affected task: 019fb845-9759-77a1-be11-593e01fe8410
Security workspace: a67d117e-802a-4fa9-a339-ca507f3f2266
Security scan: 80134abd-d94b-4234-b2dc-d11742c55b13

The backend scan was healthy when measured: status running, phase threat_model, preflight 4/4 completed, 771 files detected, no failureMessage, and no warnings.

A live Windows process snapshot showed 33 ChatGPT.exe processes, including 27 renderer processes. The renderers used about 3,305.7 MB of working set and 2,066.8 MB of private memory. Without any further user interaction, the renderer count increased from 27 to 28 in ten seconds.

Restarting Codex removes the accumulated renderers temporarily, but the loop returns whenever the Codex Security screen is opened again.

What steps can reproduce the bug?

1. Install or enable Codex Security 0.1.15 in Codex Desktop 26.727.4816.0 on Windows x64.
2. Start a standard codex-security:security-scan from a local task.
3. Open the native Codex Security workspace or return to the task that owns it.
4. Observe that the Security view crashes, blanks, or reloads.
5. In Task Manager or PowerShell, observe new ChatGPT.exe --type=renderer processes.
6. Leave the app open without interacting with the Security view.
7. Observe that additional renderer processes continue to appear while the older renderers remain alive.
8. Memory usage grows until the Codex UI becomes unstable or crashes.
9. Restart Codex and open the Security screen again; the behavior returns.

What is the expected behavior?

Exactly one renderer should own the Codex Security workspace. Closing, leaving, crashing, or reloading that workspace should dispose the old renderer and all related webContents resources. A panel failure should remain isolated and must not crash or reload the entire task view. The Desktop should also stop retrying after repeated renderer failures and show a recoverable error instead of spawning renderers without a bound.

Additional information

The measured failure is in the Desktop renderer/resource lifecycle, not in the repository being scanned or the security-scan backend.

Current-session Desktop log files for the main process were created as zero-byte files, so the initial JavaScript exception was not captured. No new Crashpad minidump or matching Windows Application Error event was present during the measured interval.

This appears related to #32180, which reports duplicate unclosable Security workspaces on Windows, but this reproduction adds automatic renderer respawning, measured multi-gigabyte memory growth, an active healthy backend scan, and a newer Desktop/plugin version. It may also share the sidebar/MCP resource lifecycle class described in #34205 and the inaccessible security-scan task behavior in #36197.

A sanitized diagnostic text file is attached. Local usernames, repository contents, prompts, and full command lines were omitted.

codex-security-renderer-loop-diagnostics-20260731.txt