[macOS][26.901.51231] 236 renderers accumulate alongside repeated Trello MCP widget initialization

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

26.901.51231 (read from installed app metadata). Chromium framework 152.0.7977.83.

What subscription do you have?

Not collected for this process-lifecycle investigation.

What platform is your computer?

macOS 26.6.2, arm64.

What issue are you seeing?

Hundreds of surviving Codex (Renderer) processes accumulated during one desktop app session. Live process inspection and app logs strongly correlate the accumulation with repeated mounting of embedded Trello tool-result widgets.

Measured during the affected session on September 7, 2026:

• 236 renderer processes, all children of the same live main app process. This is not an orphan-process pattern from multiple app launches.
• Approximately 30.37 GiB summed renderer RSS. This includes shared pages and must not be interpreted as 30.37 GiB of unique physical memory.
• App logs contain 226 mcp_app_sandbox.sandbox_requested, 226 guest_attached, 226 sandbox_document_committed, and 226 widget_running events.
• All 226 attachments use one sandbox origin, mapped by the local connector catalog to Trello.
• These events concern only 55 distinct result/widget IDs. Individual result IDs were initialized 19, 18, and 17 times, respectively, with fresh initialization IDs.
• 216 distinct guest attachment events can be paired one-to-one with distinct still-running renderers created within two seconds of the attachment. Process birth timestamps have one-second resolution. This is timing correlation, not a direct PID-to-WebContents mapping.
• Renderers survived for hours. A later check during the investigation still counted 236; no continuous idle spawning was observed during that interval.

The app and renderers were left running to preserve evidence. No restart or process termination was used as a workaround during investigation.

What steps can reproduce the bug?

Observed context: a long-running desktop session using Trello tool results and revisiting conversations. Logs show fresh sandbox initialization for the same existing result IDs.

Suggested minimal reproduction, not yet independently verified as a controlled experiment:

1. Open a conversation with an inline Trello tool-result widget.
2. Record renderer count and the widget's guest WebContents/OS process mapping.
3. Navigate to another conversation, then return to the original result.
4. Repeat and check whether new guests/renderers accumulate while previous ones survive.

Read-only counting command on macOS:

ps -axo comm | awk '/Codex [(]Renderer[)]$/ { n++ } END { print n }'

What is the expected behavior?

Revisiting existing results should not cause unbounded renderer accumulation. Obsolete widget guests should be disposed, or intentionally retained views should be reused with bounded resource consumption.

Additional information

Implementation lead, not a proven root cause: read-only inspection of the installed frontend bundle found that the MCP app component creates a webview, removes its container and clears state during cleanup, and separately aborts the widget session, requests resource teardown, and removes the webview's src attribute. No explicit webview destruction is present in those cleanup paths. A separate preview component in the same bundle explicitly invokes optional destroy() after removing a non-iframe view.

The main-process MCP sandbox registry cleans up on the guest's destroyed event. Please investigate whether detached/replaced MCP app guests actually reach destruction, and add correlated WebContents ID / OS PID lifecycle instrumentation.

Absence of an explicit destroy call alone does not prove the defect, since the framework may ordinarily handle detached guests. The repeated initialization and surviving-process measurements are the stronger evidence. Normal guest destruction is not logged by this implementation, so missing destruction log lines are not proof of missing destruction.

This appears to be a desktop widget-host lifetime issue triggered by Trello results; no Trello backend defect has been established. Local diagnostic files were preserved. Private conversation content, result identifiers, and raw logs are intentionally omitted from this public report.

Start at the MCP app component cleanup paths and the main-process sandbox registry's guest destroyed handler; compare them with the preview component's explicit destroy path. Reproduce repeated Trello widget mounting while correlating WebContents IDs with OS PIDs, then verify that obsolete guests are destroyed or reused and renderer counts remain bounded.