macOS Desktop: unfiltered ResizeObserver global errors flood logs under misleading desktop-notifications prefix

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.901.20858 (build 7658).

What platform is your computer?

macOS 26.6.2 (25G83), Apple Silicon (arm64).

What issue are you seeing?

The primary renderer emits large bursts of the following line into the Desktop log:

error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

In one process-day sample:

• 764 exact occurrences between 06:39:22Z and 09:47:37Z
• 671 while the primary window was focused and 93 while it was unfocused
• errors frequently arrived in frame-like bursts during task hydration and streaming reasoning/content updates
• normal renderer activity continued afterward
• no renderer-crash, render-process-gone, or unresponsive marker was present
• native turn notifications continued to be shown, and notification-open actions were recorded

There was no visible notification failure in this reproduction. The impact is misleading classification and substantial local log noise that obscures actionable errors.

Packaged implementation evidence

The renderer installs a generic window.addEventListener("error", ...) handler that forwards every renderer ErrorEvent to Electron at error level using the hard-coded prefix:

[desktop-notifications][global-error]

The handler has no filtering, deduplication, or rate limiting. The notification service is a separate code path; the prefix therefore makes unrelated renderer errors look like notification failures.

The same packaged bundle already contains the exact ResizeObserver message in its Sentry inbound-filter ignore list. The custom Electron forwarding path bypasses that filtering, so an event intentionally ignored by telemetry is still written hundreds of times to local logs at error severity.

Expected behavior

1. Treat the exact browser ResizeObserver guard message consistently with the existing telemetry filter: filter it, downgrade it, or emit it with bounded deduplication/rate limiting.
2. Use an accurate renderer-wide prefix such as [renderer][global-error] rather than [desktop-notifications][global-error].
3. Preserve source/stack or observer diagnostics when a renderer error is actionable.

Underlying layout condition

This report is specifically about the proven logging defect. The browser event still indicates that ResizeObserver delivery left observations for a later rendering cycle, but the forwarded event contains only the message and no callback stack. The packaged bundle has multiple observers, so attributing the underlying layout condition to a specific component from production logs would be speculative.

The underlying observer should be diagnosed separately in a source-mapped development build with early ResizeObserver instrumentation. Existing reports such as #33996 cover visible performance symptoms and reasoning-summary correlation; this macOS reproduction had log flooding without a confirmed visible UI failure.

No private prompts, thread identifiers, account identifiers, local paths, or raw logs are included.

Start by locating the renderer-wide window error handler described in the packaged implementation, then compare it with the existing Sentry inbound-filter ignore list for the exact ResizeObserver message. Trace how the handler forwards errors to Electron and verify that actionable errors retain source or stack details. Done means ResizeObserver noise is handled consistently, the prefix is renderer-wide rather than notification-specific, and normal notification behavior remains intact.