[Windows] Chrome Computer Use trusted RPC failure and GPU/mouse stutter after desktop app update

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

• #39253
• #39252
• #39173
• #39212
• #39136

Powered by Codex Action

The Trusted RPC / Chrome-control portion of this report appears to reproduce the same underlying issue described in #39252, #39212, and #39253.

However, this report also documents a separate performance regression after the recent desktop-app updates: elevated Intel GPU 3D usage and intermittent mouse stuttering that occurs only while the new ChatGPT Windows app is running and disappears when the app is fully closed.

I am leaving this issue open so maintainers can determine whether the performance regression should remain here or be tracked separately.

Additional reproducibility evidence:

I fully exited the new ChatGPT Windows app. Immediately afterward, the mouse stuttering stopped completely, system responsiveness returned to normal, and the fan noise dropped.

I then reopened the ChatGPT Windows app. Shortly after reopening it, resource usage and fan speed increased again, and mouse stuttering returned.

I also retested Chrome Computer Use after reopening the app. The same Trusted RPC dependency error occurred immediately.

This behavior is consistently tied to whether the new ChatGPT desktop app is running. No browser or website changes were made during the test.

Follow-up debugging report: partial Chrome connection with repeated page-control/CDP failures

Chat ID: 019fe1d0-45df-75a0-9883-7666f46a5da3

Date of latest reproduction: 21 August 2026

Codex App version during latest reproduction: Not recorded separately. The issue body documents version 26.814.5167.0 for the original reproduction.

The recent updates improved the original Chrome connection problem, but the connection remained only partially functional and intermittently unstable during a real WordPress/WooCommerce workflow.

Expected behavior

After connecting to my local, signed-in Chrome profile, Codex should be able to:

1. List the real open Chrome tabs.
2. Claim the selected WordPress tab.
3. Read the page DOM and form controls.
4. Click non-destructive tabs such as WooCommerce Product Data → Inventory or Variations.
5. Read and edit only the authorized stock fields.
6. Click Update once.
7. Reload the page and verify the persisted values.
8. Open the public product page and verify the customer-facing stock message.

Actual behavior

The connection was partially successful:

• Codex could reliably list my real Chrome tabs during some attempts.
• It could see the correct local WordPress tab, including its exact title and URL.
• Direct navigation to a known WordPress product URL sometimes worked.
• The Chrome sidebar could read the visible page title, location information, and full URL.

However, page-level interaction and DOM access repeatedly failed after the tab had already been discovered successfully.

Observed failures included:

• Timed out after 3000ms waiting for CDP command Page.getFrameTree
• CDP operation exceeded its deadline before command dispatch
• playwright.evaluate exceeded its deadline
• js execution timed out; kernel reset

The failures affected multiple page-control methods:

• DOM and page evaluation
• Reading WooCommerce inventory form fields
• Visible-DOM retrieval
• Reloading and rereading the WordPress page
• Clicking or inspecting controls inside the page

In several cases, listing the open tabs succeeded immediately, but claiming the already-listed tab and reading its contents timed out.

In a later attempt, @Chrome appeared to be selected and connected from the user interface, while the page-control runtime still exposed no local user tabs and showed only a separate GitHub sign-in page. At the same time, the Chrome sidebar attached to the local tab could still read some visible page content.

This behavior suggests that the extension or native-host discovery channel may be connected while the page-control/CDP channel is unavailable, incompletely attached, or attached to a different browser context.

Manual refresh did not initially resolve the problem

I manually refreshed the WordPress product page and waited for it to load fully.

After the refresh:

• Codex still saw the correct tab title and URL.
• Page-content access continued to time out.
• Both normal page evaluation and an alternative visible-DOM read failed.
• No additional automated Update was attempted because the saved state could not be verified safely.

Chrome sidebar behavior

The Chrome sidebar was tested separately.

It successfully returned:

• The current Google Maps page title.
• The Plus Code shown on the page.
• The full URL of the active Chrome tab.

This confirmed that the sidebar was attached to the correct local Chrome tab.

However, in the WordPress product editor, the sidebar reported that it could read only the text currently visible on the page. It could not reliably:

• Click the WooCommerce Inventory tab.
• Determine whether checkboxes or radio options were selected.
• Read hidden Inventory fields before I manually opened the Inventory tab.
• Perform the requested page interaction.
• Read the complete value of a long Markdown editor when only part of the text was visible.

After I manually opened the Inventory tab, the sidebar could read some visible values, such as Stock quantity, but it still could not reliably determine the selected state of Manage stock or Backorders from the extracted text alone.

The sidebar and Codex @Chrome page control therefore behaved as two different capability levels:

• Sidebar: visible-text reading worked, but interaction and form-state extraction were limited.
• Codex @Chrome control: tab discovery sometimes worked, but DOM/CDP interaction intermittently timed out or failed to attach to the intended local tab.

How we safely completed the WooCommerce work

Because automated control was not reliable enough for a live WooCommerce update, we used a controlled, manually assisted workflow:

1. Codex identified the exact product, Product ID, expected values, and fields authorized for modification.
2. I manually opened the relevant WooCommerce Inventory or Variations section.
3. I manually changed only the approved inventory fields.
4. I manually clicked Update once.
5. The Chrome sidebar confirmed the visible Product updated message and the visible stock quantity where possible.
6. When the Codex @Chrome page-control connection temporarily recovered, Codex directly reread the WordPress form controls.
7. Codex verified the persisted values:

• Manage stock enabled
• Stock quantity set to 0
• Backorders set to notify
• Stock status set to on backorder

1. Codex then opened the public product pages and verified:

• Available on backorder
• Add to Cart remained enabled

1. No Cloud Browser or generic @Computer fallback was used. The work was completed through manual assistance in the local Chrome session, combined with intermittent @Chrome readback and verification.
2. No browser backup was restored, and no price, content, SKU, product type, attribute, or variation structure was intentionally changed.

Later in the same session, page-control access became functional again without a clearly identifiable recovery event. Codex was then able to read the WordPress inventory fields and verify both variation-level data and public product messages.

This intermittent recovery makes the issue harder to reproduce consistently, but it also indicates that the WordPress pages and the user’s permissions were not the primary blocker.

Important WordPress page condition

The WooCommerce editor sometimes displayed the following warning:

The backup of this post in your browser is different from the version below.

We never selected Restore the backup.

The presence of this warning was handled as a safety condition, but it does not explain why tab discovery worked while CDP/page evaluation failed. The same page could later be read successfully without restoring the browser backup.

Impact

This issue prevented safe autonomous completion of a time-sensitive WooCommerce inventory task.

The main risk was not simply that an interaction failed. The more serious problem was that Codex could sometimes submit or attempt an Update and then lose the ability to verify whether the change had persisted.

To avoid duplicate Updates or unintended changes, automated execution had to stop, and the remaining work had to be completed through a controlled, manually assisted process.

The intermittent nature of the connection also makes the state shown as “connected” potentially misleading: tab or extension discovery may be operational while page-level control is still unavailable.

Suspected failure boundary

Based on the observed behavior, the likely failure boundary is between:

1. Chrome extension/native-host tab discovery, which may remain operational; and
2. The page-control/CDP session used after claiming the tab, which may time out, reset, or attach to a different browser context.

This is an inference from the observed symptoms, not a confirmed root cause.

Suggested engineering checks

Please investigate:

1. Why openTabs() can succeed while the subsequent claimed-tab CDP session cannot complete Page.getFrameTree.
2. Why the user interface may indicate that @Chrome is connected while no local user tabs are available to the page-control runtime.
3. Whether the claimed tab loses or delays its CDP attachment after navigation, reload, or a heavy WordPress admin page load.
4. Whether the three-second CDP dispatch deadline is too short for complex WordPress/WooCommerce admin pages.
5. Why a page-operation timeout sometimes causes the JavaScript control session to reset.
6. Whether the Chrome sidebar and Codex @Chrome task use different native-host sessions, browser bindings, profiles, or permission paths.
7. Whether multiple Chrome profiles or extension instances can leave tab discovery connected to one instance while page control attaches incompletely or to another context.
8. Whether the browser extension should expose a clearer state than connected when tab enumeration or visible-text access works but page control is unavailable.
9. Whether an automatic reconnect or safe tab re-claim should occur after Page.getFrameTree or CDP dispatch timeouts.
10. Whether page-control logs can distinguish among:

• Extension transport failure
• Native-host failure
• Tab-discovery failure
• Tab-claim failure
• CDP attach failure
• Browser-context mismatch
• Page responsiveness timeout

1. Whether the sidebar’s visible-text access and Codex page-control access are expected to operate through separate sessions or capability paths.
2. Whether the app can expose the active browser ID, profile ID, claimed tab ID, and CDP attachment state in a diagnostic view without exposing sensitive browsing data.

Please advise which logs or diagnostic package would be most useful and provide safe collection instructions.

The issue should remain open because the connection now works intermittently, but the underlying page-control failure has not been demonstrated to be permanently resolved.

Additional UI rendering and response-streaming evidence

I have identified another reproducible symptom in the new ChatGPT/Codex Windows app.

When the app is generating a response, the visible response text is rendered extremely slowly in the active window. The response appears to arrive only gradually, making it seem as though generation itself is unusually slow.

However, if I close or hide the ChatGPT window from the Windows taskbar/system-tray area without cancelling the response, and then reopen the app and return to the same conversation, the complete response is already present immediately.

Observed sequence:

1. Submit a request in the ChatGPT/Codex Windows app.
2. The response begins appearing extremely slowly in the active window.
3. Close or hide the app window without cancelling the task.
4. Reopen the ChatGPT app and return to the conversation.
5. The full response is displayed immediately.

This behavior indicates that response generation and conversation-state persistence may be completing successfully in the background, while the live rendering or streaming presentation in the Windows client is delayed or blocked.

This is consistent with the other symptoms already reported:

• Increased Intel GPU activity while the app is open
• Intermittent mouse stuttering
• General UI performance degradation
• Normal system responsiveness after the app is fully closed

This new observation suggests that the problem may involve the Windows app’s rendering loop, GPU compositor, WebView/UI layer, or handling of streamed response updates rather than the model-generation backend itself.

Suggested engineering checks:

1. Compare server-side response completion time with client-side rendered-token completion time.
2. Check whether streamed response events are received promptly but queued or rendered slowly.
3. Inspect UI-thread and compositor latency while a response is streaming.
4. Check whether minimizing, hiding, or recreating the window forces pending response content to render.
5. Compare GPU acceleration enabled versus disabled in a controlled diagnostic build.
6. Inspect whether long conversations or large DOM trees increase the rendering delay.
7. Determine whether the response view is being unnecessarily re-rendered for every token or chunk.
8. Capture timestamps for:

• First response event received
• Final response event received
• Final response text rendered
• Window reopened and full text displayed

This symptom is reproducible and further supports keeping the issue open. The backend task appears to complete, but the Windows app does not reliably display the completed response in real time.

Additional completion-state and UI lockup evidence

In addition to the slow response rendering described above, the response interface sometimes becomes completely stuck.

When this happens, the normal action controls below a completed assistant response do not appear. These include:

• Thumbs up
• Thumbs down
• Read aloud
• Copy
• Branch in new chat

Because these controls are missing, the interface continues to appear as though the response is still being generated or has not been finalized.

I have tried the following recovery steps:

1. Switch to another conversation.
2. Leave the affected conversation.
3. Return to the same conversation.

These actions do not reliably recover the missing response or completion controls.

The only reliable recovery so far is:

1. Fully terminate the ChatGPT Windows app.
2. Relaunch the app.
3. Reopen the affected conversation.

After restarting the app, the response is already complete and displayed in full, including its final state and action controls.

This indicates that the underlying task and response generation had completed successfully, but the active Windows client failed to display the completed response or transition the message from its streaming state to its finalized state.

The problem significantly reduces effective response speed because the user cannot determine whether:

• The model is still working
• The response stream has stalled
• The response has completed but has not been rendered
• The interface has failed to transition to the completed-message state

As a result, substantial time is spent waiting, switching conversations, reopening the affected chat, and finally restarting the entire application.

Suggested engineering checks:

1. Verify whether the final response-completed event reaches the Windows client.
2. Check whether the event is received but not processed or rendered by the active conversation view.
3. Investigate why the completed-message action toolbar is not created.
4. Check whether the message remains incorrectly marked as streaming in the in-memory UI state.
5. Compare the in-memory conversation state with the persisted state loaded after application restart.
6. Investigate why switching conversations does not force state reconciliation, while a full application restart does.
7. Check whether the UI thread, renderer, WebView, or GPU compositor becomes blocked before final-message rendering.
8. Add diagnostics for:

• Backend response completion
• Final stream event received
• Message state changed from streaming to completed
• Final content committed to local state
• Action toolbar rendered
• Conversation state reloaded after restart

The fact that a full restart immediately reveals the already-completed response strongly suggests a client-side rendering or state-synchronization failure rather than incomplete response generation.

This issue materially affects usability and makes ordinary responses appear much slower than they actually are.

This behavior is intermittent rather than constant. Some responses render and finalize normally, but the problem occurs frequently enough to disrupt regular work. When it occurs, I often wait for an extended period because the interface still appears to be processing the response. I eventually have to terminate and reopen the application, after which the already-completed response becomes visible.