Intermittent Computer Use failures in Chrome: UI state mismatch, noWindowsAvailable, and extension timeouts

Summary

During a prolonged workflow involving a dynamic enterprise BI dashboard in Chrome, Computer Use repeatedly became unreliable through both native macOS application control and Chrome extension control.

Some actions returned successfully without a visible change. Native control subsequently reported noWindowsAvailable even though the Chrome window remained visible. Extension control briefly worked, but then timed out while applying a filter and reading the resulting state.

Restarting the desktop app or Chrome provided temporary recovery, but the failures recurred.

Environment

• Date: September 8, 2026
• Most recent reproduction: approximately 20:35–20:41 China Standard Time (UTC+8)
• macOS: 26.5.2, build 25F84
• Desktop app display name: ChatGPT
• Desktop app bundle ID: com.openai.codex
• Desktop app version: 26.901.51231, build 8109
• Google Chrome: 152.0.7977.83
• Tool: mcp__cua_repl.js
• Control methods tested:
  • Native application control through cua.getApp
  • Chrome extension tab control through cua.getTab

The workflow used an existing authenticated browser session. This report excludes the enterprise URL, business data, screenshots, and full conversation history.

Observed Failures

1. Native control reported no available windows

Chrome still had a visible report window, but a click failed with:

Computer Use server error -10005: noWindowsAvailable

2. Successful tool responses did not consistently correspond to visible changes

An input operation such as setValue returned successfully, but subsequent screenshots showed that the input had not changed.

During an earlier attempt, date values reported in the accessibility tree also differed from the dates visible in the screenshot. This made it unsafe to assume that the requested filter had been applied.

3. Element IDs became invalid after refreshing application state

After reacquiring the application and its accessibility tree, an action using a newly returned element ID failed with:

Computer Use server error -10005: The element ID is no longer valid. Try to get the on-screen content again and see if that resolves the issue.

4. Chrome extension control connected successfully, then timed out

The extension successfully connected to the existing report tab. Entering an organization search term visibly worked, and selecting an organization changed the accessibility state to “Selected.”

The next call, which clicked the confirmation control and requested an updated accessibility state, timed out after approximately 30 seconds:

js execution timed out; kernel reset, rerun your request

It is unclear whether the timeout occurred during the click or the subsequent state retrieval.

After reconnecting through native application control, the accessibility tree still showed the organization selection popup. There was no verified evidence that the filter had been applied.

Most Recent Reproduction Sequence

1. Quit Chrome normally, reopen it, and restore the authenticated report tab.
2. Set the product and date filters. Confirm through screenshots that these changes took effect.
3. Open the organization filter through native application control.
4. Call setValue on the newly identified input field.
5. Observe that the call returns successfully, while the screenshot still shows an empty input.
6. Attempt a screenshot-based click on the input field. Receive noWindowsAvailable.
7. Connect to the same report through Chrome extension tab control.
8. Successfully open the organization filter, enter a search term, and select an organization.
9. Click the confirmation control and request the updated accessibility state.
10. Receive a timeout, followed by a tool-session reset.
11. Reacquire the native application and accessibility tree. The popup remains present.
12. Attempt to click the newly identified confirmation element. Receive an invalid-element-ID error.

Recovery Attempts and Results

• Restarted the desktop app.
• Quit and reopened Chrome.
• Reacquired application and tab handles.
• Refreshed accessibility trees and checked screenshots.
• Switched between native application control and Chrome extension control.
• Restored the existing ChatGPT Chrome extension and its original permissions with the user’s authorization.

These measures provided temporary recovery, but did not restore reliable continuous operation. The extension demonstrably connected and performed some actions successfully, so it was not simply unavailable throughout the session.

Diagnostic Limitations

• The user had used the computer earlier. There is no controlled evidence establishing that user interaction or window focus changes caused these failures.
• One separate call used an incorrect coordinate argument format. That was an agent invocation error and is excluded from the product-failure evidence.
• The issue has not yet been reproduced on a minimal public test page.
• The root cause is undetermined. Possible areas for investigation include native window control, accessibility-state synchronization, extension session handling, and compatibility with the dynamic dashboard.

Expected Behavior

• Successful actions should correspond to the requested UI change, or clearly indicate that execution could not be verified.
• Accessibility state and screenshots should reflect the same current interface state.
• A visible, accessible Chrome window should remain controllable, or the tool should provide an actionable explanation of why it is unavailable.
• Refreshing application state should provide usable element references.
• Timeouts should leave the session in a recoverable state, with clear guidance on whether an action may have executed.

Impact

The failures interrupted a substantial data-verification workflow. Each filter change required additional visual checks to avoid accepting data from the wrong date or organization scope.

Unverified results were not written to the output ledger, and previously completed work was preserved. However, repeated recovery attempts significantly reduced throughput and prevented completion of the remaining work.

Request to the Codex Team

Please investigate:

1. Why native control reports noWindowsAvailable while Chrome still has a visible report window.
2. Why some input actions return successfully without a corresponding visible change.
3. Why accessibility state can disagree with screenshots.
4. Why newly retrieved element references become invalid.
5. Why extension control can connect and perform initial actions successfully, then time out during filter confirmation or state retrieval.
6. Whether there is a known issue, a recommended diagnostic procedure, or a release containing a relevant fix.

Start with the mcp__cua_repl.js workflow and compare cua.getApp native control with cua.getTab extension control. Reproduce the reported sequence while checking screenshots, accessibility trees, element IDs, and timeout recovery. Done means identifying the failure boundary and documenting a reliable fix or actionable diagnostic guidance.