[macOS][In-app Browser] Opening Google times out after 30 seconds and leaves about:blank (26.901.20858) #42459

What version of the Codex App are you using?

26.901.20858 (build 7658), read from the installed app's Info.plist.
The installed app is named ChatGPT.app and has bundle identifier com.openai.codex.

What subscription do you have?

Not recorded in this test.

What platform is your computer?

macOS 26.6.2 (build 25G83), Apple Silicon.

uname -mprs: Darwin 25.6.0 arm64 arm

What issue are you seeing?

During a single speed test using only the desktop app's built-in browser through mcp__cua_repl, opening Google timed out after 30.0514 seconds and reset the JavaScript kernel. The resulting tab remained at about:blank.

The exact call was:

var tab = await cua.createBrowserTab("iab", "https://www.google.com", { visible: true });

The tool used its default 30,000 ms execution timeout and returned:

js execution timed out; kernel reset, rerun your request

After the reset, cua.getState() showed a Codex In-app Browser tab with both title and URL equal to about:blank. Attaching to that tab and reading its DOM returned an empty string. The Google navigation was not retried.

What steps can reproduce the bug?

These are the steps from the observed run; repeatability has not been established:

1. In a desktop task, use mcp__cua_repl with the default 30-second tool timeout.
2. Run the cua.createBrowserTab call above as the first CUA call.
3. Observe the timeout and kernel-reset error.
4. Call await cua.getState() after the reset and inspect the created tab's URL.
5. Attach to that tab using cua.getTab and read it with tab.playwright.domSnapshot().

The intended benchmark was: open Google, read the DOM, enter grok latest news, press Enter, read search results, click a result and confirm navigation, then create an about:blank tab and separately measure DOM reading and screenshot capture. The search-dependent steps could not proceed because Google did not open.

Measurements

API duration was measured around awaited calls using Date.now() where possible. Tool duration is the tool-reported wall time, excluding model thinking time. The first call timed out before an API duration could be collected. These are single samples, not averages.

The new blank tab's DOM measurement failed with ReferenceError: blank is not defined because of an agent-authored test-script variable error. This is not being reported as a browser defect. The new blank tab was subsequently attached to for the separate screenshot test; the failed DOM measurement was not retried.

What is the expected behavior?

Opening a URL through the built-in browser should either load the requested page or return an actionable navigation error. In this run, the only error was a generic tool execution timeout followed by a kernel reset, leaving the tab at about:blank and preventing the requested workflow from continuing.

Additional information

• Only one approximately 30-second delay was observed. This report does not claim repeated 30-second delays or consistent reproduction.
• The agent did not restart the desktop app before or during the test. Whether the user restarted it before the session is unknown. The tool's automatic JavaScript kernel reset was not an app restart.
• Browser measurements used only mcp__cua_repl, cua, and the in-app tab's playwright/screenshot APIs. No external browser, terminal Playwright, or search tool was substituted.
• No failed benchmark operation was retried. No root-cause investigation or network diagnosis was performed, so this report does not establish whether the timeout originated in navigation, initialization, network conditions, or another component.
• Related reports with different platforms or triggers: Windows Codex Chrome/Computer Use browser control fails: about:blank, JS kernel timeout, and URL detection failure #40048 (Windows browser-control failures, including a kernel timeout) and [Desktop/macOS] Opening an active Browser task blocks the app for ~31 seconds #36703 (macOS UI stalls when opening an active Browser task). This report records a macOS URL-opening timeout on the version above, not the task-switching stall described in [Desktop/macOS] Opening an active Browser task blocks the app for ~31 seconds #36703.