[Windows] Restored localhost Browser sidebar leaves renderers at sustained high CPU

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

• Windows package: OpenAI.Codex_26.818.8289.0_x64
• Chromium framework: 151.0.7922.170
• Bundled app-server / CLI: 0.149.0-alpha.4.3
• In-app Browser release: 26.818.61809

What subscription do you have?

Omitted for privacy.

What platform is your computer?

Windows 11 25H2, build 26200, x64; 12 logical processors.

What issue are you seeing?

Restoring an existing Codex task with an in-app Browser sidebar pointed at a stopped local development server (http://localhost:3000/) can leave additional Chromium renderer processes in a sustained high-CPU state.

The Browser sidebar created two additional renderer processes at the same timestamp. The sanitized desktop log sequence was:

IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=http://localhost:3000/
mcp_app_sandbox.attach_unmatched guestWebContentsId=<redacted> url=undefined urlProtocol=invalid
IAB_LIFECYCLE did attach browser sidebar webview ...
browser sidebar dom-ready ... url=http://localhost:3000/

Nothing was listening on port 3000. After the restore, the Codex process group stayed around 35% CPU and roughly 2.2–2.6 GiB working set even while the app-server was idle. Switching to a different small task did not lower CPU.

Five-second sample on a 12-logical-processor machine:

Force-terminating only the two additional renderers immediately recovered the app. Electron recreated clean renderer processes automatically.

Post-recovery sample:

No app-server restart, task deletion, cache reset, or full application restart was required.

The main desktop log also contained repeated frontend errors while the app was hot:

ResizeObserver loop completed with undelivered notifications.

This points to an in-app Browser/webview lifecycle or cleanup failure rather than model execution or Git scanning.

What steps can reproduce the bug?

1. On Windows, open a Codex task and create an in-app Browser sidebar tab for http://localhost:3000/.
2. Stop the local dev server.
3. Leave the Browser tab/task persisted and navigate away.
4. Later reopen/resume that task so Codex restores the Browser sidebar.
5. Observe the Browser lifecycle log around webview creation and attachment.
6. If the failure occurs, observe sustained CPU in Electron main plus renderer processes even after switching tasks.
7. Verify that codex app-server remains near idle.
8. Terminate only the pair of additional renderers created during Browser restoration.
9. Observe CPU and memory return close to idle while Electron recreates clean renderers.

The trigger may be timing-sensitive. The strongest correlation was the restored Browser sidebar targeting a stopped localhost server together with mcp_app_sandbox.attach_unmatched.

What is the expected behavior?

• An unavailable local Browser target should show a bounded connection error and return to idle.
• Browser/webview renderers should be disposed when their task or sidebar is inactive.
• Failed attachment or navigation should use bounded retry/backoff.
• Switching away should release Browser renderer CPU and memory.
• Recovery should not require manually terminating child renderers.

Additional information

A Task Manager screenshot is available but is not attached because the issue connector cannot upload local attachments.

Privacy: no account identifiers, task/thread/session IDs, local workspace paths, hostnames, pipe names, raw log archives, or private task content are included.

Goodwill request

Substantial paid Codex usage and time were spent isolating this desktop-app defect, collecting process-role measurements, finding the exact Browser lifecycle trigger, and verifying a renderer-only recovery. If OpenAI has an applicable goodwill program, please consider a usage credit, temporary limit increase, bug-reporter recognition, swag, or another small thank-you for the reproducible report.

Start by reproducing the Windows restore flow for an in-app Browser sidebar targeting a stopped localhost:3000 server, then inspect the renderer-created, attach_unmatched, did-attach, and dom-ready lifecycle events described in the report. Confirm that failed navigation or attachment reaches bounded idle behavior, inactive sidebars release renderer resources, and switching tasks does not require terminating child processes.