›_ Codex Issues
Codex Issues / #35083

[macOS App] In-app Browser sessions retain Chromium renderers after activity ends (disposeAfterSessionActivity=false)

Open 💬 3 comments Opened Jul 24, 2026 by shuirna
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop on macOS, bundled Codex Framework / Chromium version 150.0.7871.124.

What platform are you using?

macOS on Apple Silicon.

Summary

Codex Desktop accumulated approximately 70 direct child Codex (Renderer) processes during one long-running app session. Approximately 66 were long-lived, low-memory sleeping renderers.

Fully quitting and restarting Codex reduced the renderer count immediately from 70 to 2. The fresh session remained at 2 renderers.

Desktop logs correlate the accumulation with in-app Browser Use sessions created for background automations and subagent tasks:

  • 35 distinct Browser Use hosts were created.
  • 35 Browser Use sessions ended.
  • 34 of the 35 created hosts had no matching host-disposal event.
  • 33 of the 35 ended sessions had no matching disposal event.
  • 172 lifecycle records used disposeAfterSessionActivity=false.
  • After the Browser Use route disappeared, requests repeatedly failed with No ChatGPT browser route is available for browser session ....
  • Debugger-listener teardown recorded webContentsDestroyed=false.

This suggests that ending Browser Use activity removes or loses the route but does not destroy the corresponding guest WebContents/renderer. The dormant renderers remain for the lifetime of the desktop process.

The accumulated renderers correlated with severe typing and scrolling latency in Codex Desktop and Microsoft Word. Restarting Codex cleared the renderers and restored responsiveness.

Steps to reproduce

  1. Start Codex Desktop from a clean launch and record the number of direct Codex (Renderer) child processes.
  2. Run multiple tasks, background automations, or subagents that use the built-in in-app Browser.
  3. Allow those Browser Use activities to complete.
  4. Navigate away from or finish the associated tasks.
  5. Inspect the Codex process tree.
  6. Observe that Browser Use sessions have ended but additional renderer processes remain alive.
  7. Repeat browser-using tasks and observe the renderer count accumulating.
  8. Fully quit and relaunch Codex; observe the count returning to the normal baseline.

Expected behavior

When a Browser Use session ends and no live UI route owns its browser host, Codex should destroy the guest WebContents and terminate or reuse the corresponding renderer after a bounded retention period.

Background automations and subagents should not leave a renderer alive for the remainder of the desktop application's lifetime.

Actual behavior

The session activity ends with:

disposeAfterSessionActivity=false

The route subsequently becomes unavailable, but the associated renderer or guest WebContents remains alive. Renderer processes accumulate until the entire Codex application is restarted.

Sanitized lifecycle signature

IAB_LIFECYCLE received browser sidebar webview host created
IAB_LIFECYCLE ended browser use session activity
disposeAfterSessionActivity=false

IAB_LIFECYCLE iab backend info request failed
errorMessage="No ChatGPT browser route is available for browser session ..."

IAB_LIFECYCLE unregistered debugger listener
webContentsDestroyed=false

Controlled observation

| State | Renderer processes |
| --- | ---: |
| Long-running affected app session | 70 |
| Low-memory sleeping renderers | approximately 66 |
| Immediately after full restart | 2 |
| Fresh-session follow-up | 2 |

Suggested diagnostic/fix areas

  • Dispose Browser Use hosts when session activity ends and no live route or UI owner remains.
  • Add a bounded idle timeout for detached IAB guest WebContents.
  • Reuse an existing safe browser host where possible instead of creating one per background task.
  • Ensure automation/subagent completion triggers Browser Use host cleanup.
  • Treat a missing browser route as a cleanup signal rather than retaining an unreachable host.
  • Log a stable host/WebContents identifier at creation, session end, route disposal, guest teardown, and renderer exit so lifecycle balance can be verified.

Privacy note

Raw desktop logs are not attached because they contain private task text, local paths, credentials, and authenticated URLs. Additional targeted, sanitized lifecycle excerpts can be provided privately if requested.

Related issues

  • #33469 — persistent renderers from integration-heavy tasks
  • #34890 — renderer accumulation and OOM loop
  • #29585 — IAB route loss with disposeAfterSessionActivity=false

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34890

Powered by Codex Action

QZQ-go · 24 days ago

I can reproduce the same lifecycle signature on macOS, with an additional impact: a retained Browser Use renderer can remain actively hot and continuously drive the shared GPU process rather than merely sleeping.

Environment

  • Codex Desktop: 26.727.51351 (build 6119)
  • Embedded Chromium/Codex Framework: 150.0.7871.182
  • macOS: 26.6 (25G72), Apple Silicon
  • Hardware: Apple M4, 10-core GPU
  • Displays: internal Retina plus external 3840x2160 at 60 Hz

Observed behavior

Activity Monitor showed:

  • Codex GPU service: approximately 90% CPU, 32.7% GPU
  • WindowServer: approximately 115% CPU, 22% GPU
  • Multiple Codex (Renderer) processes at approximately 41% and 29% CPU

The high-GPU process was confirmed from its command line as Chromium's shared --type=gpu-process child.

One Browser Use WebView was created at 14:22:38. The corresponding renderer process had the exact same launch time. About 22 seconds later, desktop logs recorded a CDP timeout and debugger-listener teardown with:

reason=cdp-timeout
webContentsDestroyed=false

That renderer remained alive and active more than 20 minutes later, typically consuming approximately 18-25% CPU. It continued feeding work to the shared GPU service, which remained around 22-40% CPU even after other browser previews were unloaded.

Two additional Browser Use WebViews created at approximately 14:29:34 and 14:29:40 mapped to two newer renderer processes. During a controlled hide/restore test:

  • Before hiding: four active renderers together used roughly 58% CPU; the GPU service used roughly 57-74% CPU and briefly reached approximately 95%.
  • Hiding the Codex window caused the two newer browser renderers to exit.
  • The older renderer associated with the CDP timeout remained alive and hot.

A process sample of the GPU service showed sustained Metal/AGX render submission. Its physical footprint was approximately 1.1 GB with a 1.9 GB peak. The GPU driver reported recoveryCount=0, and I found no GPU reset/context-loss event, so this appears to be retained WebContents/rendering activity rather than a hardware or driver recovery loop.

Impact

The retained renderer and shared GPU load caused severe stuttering on the external display. Fully quitting and relaunching Codex clears the renderer and restores responsiveness; merely finishing the Browser Use activity does not.

This suggests the retained guest WebContents can remain actively rendering after a CDP timeout. A bounded cleanup path for timed-out/unrouted Browser Use hosts, plus background frame throttling for inactive WebViews, would address both renderer accumulation and sustained GPU impact.

teamleaderleo · 1 day ago

Reproducing this on Framework 151. After approximately 16 hours of normal use, 32 direct-child Codex (Renderer) processes were still alive. Renderer client IDs had reached 230; their summed RSS was approximately 4.9 GiB, with the largest renderer around 955 MiB.

Environment

  • ChatGPT/Codex Desktop 26.818.61809 (build 7019)
  • Codex Framework 151.0.7922.170
  • macOS 26.6.2 (25G83)
  • MacBook Air Mac17,4, Apple M5, 24 GB RAM

The current session logs contain these lifecycle events:

disposeAfterSessionActivity=false         87
ended browser use session activity        65
disposed browser use host                  0
No ChatGPT browser route is available     32
webContentsDestroyed=false                70
unregistered debugger listener            70

These are raw event counts, not unique sessions. Browser activity ended repeatedly, no host-disposal event was recorded, and 32 renderers remained alive. This reproduces the retained Browser Use WebContents lifecycle on the newer Framework 151 build.

Only one SkyComputerUseService was running, so this is distinct from the separate helper-respawn loop.