[macOS][26.1027.30824] Chat switching lag after PDF preview; getAnnotations/sendWithPromise errors; restart ineffective

Summary

On the unified ChatGPT / Codex macOS desktop app, the user reports noticeable lag when switching between chats in Work and Codex modes. Restarting the application did not resolve the lag.

Read-only diagnostics found sustained activity in the primary Codex renderer, repeated ResizeObserver errors, and fast logged thread-read operations. These are correlated observations; the root cause has not been established.

Follow-up: user identifies PDF preview as the onset; PDF-specific stack found

After the original report, the user clarified that the lag began after opening previews of two recently generated study-guide PDFs, rather than during PDF generation itself. The user reports that subsequent chat switching remained laggy even after restarting the application.

A closer read of the same preserved pre-restart log found that the previously reported sendWithPromise null-reference errors have a PDF-specific stack:

2026-10-30T19:59:06.737Z error [electron-message-handler] [desktop-notifications][unhandled-rejection] TypeError: Cannot read properties of null (reading 'sendWithPromise')
    at Dr.getAnnotations (app://-/assets/pdf-3c562be560a8.js:3:221150)
    at Tr.getAnnotations (app://-/assets/pdf-3c562be560a8.js:3:204463)
    at u (app://-/assets/pdf-preview-panel-ce10957cf866.js:2:14968) rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true

• The first such PDF-stack record in that application log is at 19:59:06.737 UTC (03:59:06.737 Asia/Shanghai on October 31).
• Four more records share the timestamp 20:07:53.335 UTC.
• A sixth record appears at 20:14:07.066 UTC. The original count of five was an earlier snapshot, not a contradiction.
• Retrieved local task records confirm PDF creation/update work and repeated rendered-page image inspections around this period. One initial PDF-generation turn completed at 19:58:50 UTC, approximately 17 seconds before the first PDF-stack error.
• The four PDF variants currently present in the two output folders range from 383,431 to 1,164,613 bytes (roughly 0.37–1.11 MiB). This is an aggregate file-size check, not proof of document validity or proof of which variant was opened.
• Generic ResizeObserver errors were already present in this process at 19:06:47 UTC, before these PDF tasks. Their mere presence therefore cannot establish the reported onset or implicate PDF preview by itself.

Suggested updated reproduction:

1. Generate a study-guide PDF in a chat.
2. Open the PDF in the application's built-in preview.
3. Switch between existing chats, including the chats containing the PDF outputs.
4. Observe whether navigation becomes laggy and whether the PDF getAnnotations rejection appears.
5. Restart the application and compare again; check whether restored previews reproduce the problem.

This is a user-observed temporal trigger plus a matching PDF-specific error stack, not a controlled proof that annotation loading causes the lag. The user subsequently confirmed that closing both PDF previews did not restore responsiveness; see the later follow-up below. Whether restored panels explain persistence after restart and whether an external PDF reader reproduces anything remain untested. No PDF preview was reopened to force a reproduction, and no source PDF or private chat content has been uploaded.

Please prioritize PDF-preview lifecycle/worker validity during annotation requests and its interaction with chat switching/restored panels, while preserving the broader renderer investigation above.

Environment

• Installed application: ChatGPT.app
• Bundle identifier: com.openai.codex
• Desktop version: 26.1027.30824
• Build: 22943
• macOS: 27.0.1 (26A434)
• Physical memory: 16 GiB
• Logical CPUs: 10
• Observed locally on October 31, 2026, approximately 04:07–04:16 Asia/Shanghai (October 30, approximately 20:07–20:16 UTC).
• Subscription tier omitted.

User-visible behavior and reproduction

1. Open the desktop application with the existing local profile and saved chats.
2. Switch between existing chats using the sidebar.
3. Observe lag while navigating between chats.
4. Restart the application and repeat: the user reports the lag persists.

The user specifically identified chat switching as the problem, rather than only waiting for model responses. Click-to-visible latency has not yet been measured. A controlled short-chat versus long-chat comparison has not been completed. A full macOS reboot has not been confirmed.

Expected: chat navigation should remain responsive, and loading historical content should not block the primary interaction window.

Read-only observations

Before the application restart

• Sampled primary Codex (Renderer) CPU values were approximately 92–102% (roughly one logical core).
• Whole-system CPU remained approximately 72–83% idle across the collected snapshots.
• The renderer's top MEM reading increased from about 1.4 GB to about 2.0 GB during the short observation window. This does not establish a memory leak.
• One inspected main log contained 1,019 occurrences of the ResizeObserver message below and five occurrences of the null-reference error below at the time of inspection. Counts are cumulative within that log snapshot, not per-minute rates or unique failures.

Sanitized original lines:

2026-10-30T20:08:35.533Z error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications. rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true

2026-10-30T20:07:53.335Z error [electron-message-handler] [desktop-notifications][unhandled-rejection] TypeError: Cannot read properties of null (reading 'sendWithPromise')

The logger prefix is reproduced verbatim; it does not establish a notification-delivery fault.

After the application restart

A new application process and log confirmed that the application had restarted.

• Primary renderer CPU was approximately 76.8% in a post-restart snapshot; whole-system CPU was approximately 74% idle.
• The new main-log snapshot contained seven ResizeObserver messages, including:

2026-10-30T20:15:55.014Z error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications. rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true

Selected response_routed duration fields in that new log:

These are durations reported for those operations, not end-to-end sidebar-click-to-usable-view measurements. They do not exclude delays before/after the operations or prove that every sampled operation belongs to a visibly slow switch.

Local data and system context

• Approximately 142 GiB disk space available.
• No thermal or performance warning was reported by pmset -g therm when checked.
• Approximately 1.2 GB swap was in use before the application restart; memory compression was present. Resource contention is therefore not completely excluded.
• Aggregate local session metadata: 60 JSONL files, about 444 MiB total; largest file about 52 MiB.
• Global state file: approximately 2.46 MiB; queued-follow-ups was an empty object.
• This does not match the specific hundreds-of-MB queued-image-state condition described in #53427.
• Sampling occurred while this diagnostic chat was active; no controlled idle baseline or synchronized renderer profile was captured.

Related reports and limits

• #58367 — especially close same-version macOS report (26.1027.30824): opening/scrolling even a small PDF makes the entire UI laggy with elevated renderer CPU; the reporter says closing the preview restores responsiveness. Their follow-up reports about 140% renderer CPU during PDF interaction and 0–10% after leaving it idle for 30 seconds. This is another user's result, not a test completed on this machine. That report does not publish the same getAnnotations/sendWithPromise stack, so a shared root cause remains unconfirmed.
• #33782 — similar macOS chat-switch freezes and ResizeObserver observations.
• #11011 — broader thread-switching latency.
• #53427 — local-state-dependent macOS desktop lag; the oversized queued-image condition in that report was not present in this inspection.

These are related symptoms, not confirmed duplicates. The observed ResizeObserver and null-reference messages do not by themselves identify the cause, prove a GPU fault, or establish that local history size is responsible. The user subsequently identified the onset as occurring after opening generated PDF previews, as described in the follow-up above; the exact root cause and relationship to an application update remain unknown.

Please investigate the chat-switch render/layout path and advise on a supported performance capture or mitigation that preserves existing chats, configuration, and active work.

This report was prepared and submitted by Codex at the user's explicit request. Raw conversation history, chat identifiers/titles, local user paths, credentials, screenshots, and full logs are not included.

Follow-up: closing both PDF previews did not restore responsiveness

The user now explicitly reports that both PDF preview windows/panels have been removed/closed, but chat switching remains noticeably laggy. This is a user-confirmed observation; closure was not independently inspected through the UI.

Read-only checks around October 31, 04:37–04:39 Asia/Shanghai found:

• No new getAnnotations/sendWithPromise rejection in the current post-restart main log.
• ResizeObserver errors continued, including 17 records between 20:37:50 and 20:39:06 UTC. Counts are records, not unique failures.
• Renderer CPU fluctuated: approximately 56–59% in one interval, 106% in another, and about 71% falling to 10–13% in a later short interval. Whole-system CPU had substantial idle capacity and the system memory-pressure level was normal.
• Local thread/read remained fast in most cases (later window median 1 ms, maximum 246 ms); thread/list median 1 ms, maximum 4 ms; two thread/resume calls were at most 260 ms. These are operation durations, not end-to-end navigation timing.
• Plugin/tool-status discovery had some multi-second operations (a prior five-minute window included one plugin/list at 5,022 ms and mcpServerStatus/list up to 8,089 ms). It has not been established that these background operations block navigation.
• Two short native renderer samples were mostly in message waiting on the main thread (approximately 93% and 88% of main-thread samples). They did not capture a sustained attributable freeze; some framework symbols are ambiguous/stripped, and there were no synchronized click timestamps.
• Chat-list HTTP 429 errors occurred earlier at 20:33:43 UTC, but did not recur in the later 20:37:50–20:39:06 UTC inspection window.

This limits the earlier PDF-trigger hypothesis: the reported onset followed PDF preview, but closing those previews has not been sufficient to recover this user's responsiveness. We cannot currently distinguish retained state after the PDF interaction from a broader desktop navigation/rendering or tool-discovery problem. No source files, raw native samples, or private conversation identifiers were uploaded.

Follow-up: multiple PDF-associated chats are affected, not just the original two

The user has now manually tried switching to several other chats/windows and reports that the lag appears whenever the selected chat involves PDFs. The observed scope is therefore broader than the two recently generated study-guide PDFs described earlier.

This is the user's report from trying multiple chats, not an independently instrumented A/B test. The exact number of chats and files was not recorded. It remains unverified whether non-PDF chats are consistently smooth under comparable conditions, whether every affected chat restores a PDF preview, or whether PDF-related content in the transcript is sufficient to trigger the lag without an open preview.

Please interpret the earlier report that closing the original two PDF panels did not help in this broader context: other PDF-associated chats/windows may also participate. A PDF preview/restoration or PDF-associated chat-activation path is a stronger investigation target based on the newly reported pattern, but no single mechanism or universal claim that all PDFs cause the problem has been confirmed.

A useful controlled comparison would distinguish: (1) switching to a short chat without PDF content; (2) switching to a PDF-associated chat with its preview closed; and (3) explicitly opening the same PDF preview. No further previews were opened by the diagnostic assistant to force a reproduction, and no private chats or PDF files are attached.