[macOS][26.810.52044] App reaches 23.4 GiB after long idle; five equal renderer processes coincide with five pet surfaces

[Choudhry18]

[macOS][26.810.52044] App reaches 23.4 GiB after long idle; five equal renderer processes coincide with five pet surfaces

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

ChatGPT/Codex desktop app 26.810.52044 (6662).

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

• macOS 26.5.1 (25F80)
• Mac mini (Mac16,10)
• Apple M4, 10 CPU cores
• 32 GB unified memory

What issue are you seeing?

After I left the desktop app open over a weekend, I returned to a system under severe memory pressure. macOS showed the ChatGPT/Codex application family using more than 23 GB of memory, and other applications were paused or unresponsive.

A macOS JetsamEvent from the incident reports the ChatGPT/Codex coalition at approximately 23.389 GiB resident. It lists five Codex (Renderer) processes with nearly identical ages and memory sizes. Each had approximately 238,000 resident 16 KiB pages, or about 3.6 GiB resident memory:

Renderer PID	Approximate resident memory
52435	3.6 GiB
52436	3.6 GiB
52437	3.6 GiB
52438	3.6 GiB
52443	3.6 GiB

The equal process ages and sizes suggest a shared renderer lifecycle or repeated allocation pattern. They do not look like normal memory use for one chat window.

Pet and browser lifecycle evidence

The desktop log shows that one visible pet was implemented as five native composition surfaces. The app created all five within about 0.2 seconds on 2026-08-21 at approximately 20:56:20 UTC:

Surface	Electron webContents ID
voice-microphone	11
voice-controls	12
voice-output	13
mascot-badge	14
activity-slot-0	15

The lifecycle sequence for each surface included created, load-url, did-finish-load, connected, mounted, painted-before-attach, native-attached, and presented.

The built-in browser used separate web contents during the same period. The primary browser page used webContentsId=6; another browser tab later used guestWebContentsId=9. The primary application UI used webContentsId=1. The root avatar overlay used webContentsId=3.

This is an important limitation: the JetsamEvent contains operating-system PIDs, while the application log contains Electron webContents IDs. There is no historical webContents.getOSProcessId() mapping in the available logs. Therefore, the five-to-five relationship is a strong correlation, not direct proof that PIDs 52435–52443 were webContents 11–15.

Turn-state errors in the avatar overlay

The root avatarOverlay renderer (rendererWebContentsId=3) received full conversation lifecycle events. During the affected period, it repeatedly logged errors such as:

Received turn/started for unknown conversation
Item not found in turn state itemId=call_[REDACTED]
Dropping output delta for unknown item

The affected session was large:

• Session ID: 01a01fa9-cbce-7e10-a19d-45fa95dac72d
• Local rollout JSONL size: approximately 34 MB
• The task contained substantial tool output and used the built-in browser.

Please tell me if a private support channel is preferred for the session ID or sanitized logs. I will not upload the full rollout because it can contain prompts, tool output, file paths, and other private data.

Local production-bundle observations

I inspected the installed, signed production bundle to understand the process topology. The code is minified and has no source maps, so these observations identify likely investigation areas and do not establish the root cause:

• Native pet composition creates a separate Electron BrowserWindow for each surface.
• The surface windows use backgroundThrottling: false.
• The code also calls webContents.setBackgroundThrottling(false).
• Surface windows persist until a surface is explicitly removed or fails.
• Conversation output deltas are queued and flushed on a short interval.
• When an output delta refers to an unknown command item, the renderer searches existing turns for that item and logs Item not found in turn state during the search.

The logged pet preparation messages had small geometry and low activity counts. There was no evidence of an oversized canvas or bitmap. This makes a simple pet-pixel allocation less likely than retained JavaScript state, repeated IPC subscriptions, pending output data, or unreleased compositor resources.

What steps can reproduce the bug?

I have one well-documented incident, but I do not yet have a short deterministic reproduction. The observed sequence was:

1. Enable and show one pet with its activity UI.
2. Use a large Codex task with substantial tool output and some built-in browser activity.
3. Leave the desktop application running for the weekend.
4. Keep the Mac awake. The affected machine had system sleep, display sleep, and disk sleep set to 0.
5. Return to the Mac and inspect Activity Monitor or the macOS JetsamEvent.
6. Observe that the ChatGPT/Codex application family has grown beyond 23 GB and that multiple renderer processes have multi-gigabyte resident sizes.
7. Fully quit and reopen the app. Memory returns to a normal range.

A useful controlled reproduction would compare the following cases over several hours with the same large task:

1. Pet disabled; built-in browser closed.
2. Pet disabled; built-in browser active.
3. Pet enabled; built-in browser closed.
4. Pet enabled; built-in browser active.

Each test should record surfaceId, webContents.id, webContents.getOSProcessId(), process memory, IPC listener counts, queued output bytes, and renderer creation/destruction events.

What is the expected behavior?

• Long-lived idle renderer memory must remain bounded.
• One pet must not cause several multi-gigabyte renderer processes.
• Inactive voice and activity surfaces must stop work or be destroyed.
• Hidden surfaces must not process the complete conversation event stream.
• Output deltas for unknown items must be discarded without retaining data or repeatedly scanning the full turn list.
• Quitting the app must not be required to return memory to a normal level.

Additional information

Working hypotheses

These hypotheses are ordered by how well they fit the evidence. They are not confirmed root causes.

1. An output-event or turn-state retention leak in the avatar overlay or pet surfaces.
2. IPC listeners are added during repeated mount or preparation cycles and are not removed during detach.
3. Transparent Chromium surface or IOSurface resources are replaced but not released.
4. Inactive voice surfaces stay alive with background throttling disabled.
5. The built-in browser increases event volume or supplies the triggering activity, but it does not by itself explain five equal renderer processes.
6. The JetsamEvent can include shared-memory accounting, so part of the apparent per-renderer equality could be shared Chromium or compositor memory. Per-PID vmmap data was not captured before the processes ended.

Suggested instrumentation and safeguards

Please consider:

• Log surfaceId, webContents.id, and webContents.getOSProcessId() when every application, browser, and pet renderer is created or attached.
• Record renderer heap, private memory, resident memory, listener counts, pending event count, and pending event bytes.
• Send only a compact activity summary to pet surfaces. Do not send the full thread event stream.
• Drop stale output deltas before scanning or cloning task state.
• Remove IPC listeners, timers, and pending queues when a surface detaches.
• Destroy inactive voice surfaces or enable background throttling while they are idle.
• Add a long-duration memory regression test for one large task with the pet enabled.
• Add telemetry that distinguishes primary, browser, avatarOverlay, and each native pet surface in crash and memory reports.

Example diagnostic data at renderer creation:

logger.info("renderer-created", {
  surfaceId,
  webContentsId: window.webContents.id,
  osPid: window.webContents.getOSProcessId(),
});

Related reports

• Abnormally high ram usage in mac app #18589 — Abnormally high RAM usage in the macOS app: Abnormally high ram usage in mac app #18589
• Codex Desktop (macOS): renderer OOM crash loop (~5 min) with many concurrent threads — unbounded thread history retention, post-reload refetch storm, 170+ leaked renderer processes #34890 — macOS renderer OOM loop and leaked renderer processes: Codex Desktop (macOS): renderer OOM crash loop (~5 min) with many concurrent threads — unbounded thread history retention, post-reload refetch storm, 170+ leaked renderer processes #34890
• [Windows][26.727.6591.0] Avoid creating unused avatar-overlay renderer and bound renderer lifecycle #36980 — Unused avatar-overlay renderer and lifecycle bounds on Windows: [Windows][26.727.6591.0] Avoid creating unused avatar-overlay renderer and bound renderer lifecycle #36980
• Codex Desktop Computer Use can trigger memory runaway to 172GB on macOS #26738 — macOS Computer Use memory runaway: Codex Desktop Computer Use can trigger memory runaway to 172GB on macOS #26738
• Codex Desktop on macOS gets stuck thinking after interrupted/resumed turn with Item not found in turn state #24571 — Item not found in turn state after interrupted or resumed turns: Codex Desktop on macOS gets stuck thinking after interrupted/resumed turn with Item not found in turn state #24571

Attachments available after privacy review

• Sanitized JetsamEvent excerpt with coalition and per-renderer memory values.
• Sanitized desktop-log excerpt with pet surface creation and webContents IDs.
• Sanitized browser lifecycle excerpt showing separate browser webContents IDs.
• Sanitized avatar-overlay errors around the affected session.
• Activity Monitor screenshot, if required.

Disclosure: This issue was prepared with AI assistance from local diagnostic evidence. The account owner reviewed it before submission.

[github-actions]

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

• Codex Desktop Crashes While Idle as Computer Use Workers Multiply #39110

Powered by Codex Action