Repository navigation
Chrome browser control times out creating about:blank after 30 seconds #45016
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.908.31748 (build 8720), previously recorded; exact version at failure time not independently verified.
What subscription do you have?
ChatGPT Pro
What platform is your computer?
macOS 26.4 (25E246), previously recorded.
What issue are you seeing?
Chrome browser control timed out while creating an about:blank tab through mcp__cua_repl.js. Tab creation was not confirmed; no target website navigation was attempted.
Tool-reported duration: 30.0480 seconds.
Exact error:
js execution timed out; kernel reset, rerun your request
This report concerns this specific timeout, not the separate earlier 'nodeRepl.fetch request failed' symptom. It occurred before visiting help.openai.com; it does not establish that all URLs fail.
Feedback ID: 01a08f35-4ae1-7d73-a0e3-fbcc35d2deba
Task ID: 01a094c1-4408-7ae2-ad71-48fc1bbceeab
Turn ID: 01a094f2-922d-7c32-a718-18a4d42954bf
Tool call ID: call_f8OgRcEdVT9apMEIyIyUYi0d
Time: 2026-09-12 09:28:50.336–09:29:20.389 UTC (17:28:50.336–17:29:20.389 Asia/Shanghai). The timestamp difference is approximately 30.053 seconds, separate from the tool-reported duration.
What steps can reproduce the bug?
Recorded failed test (no new reproduction performed):
- In a Codex desktop task, request Chrome extension control.
- Invoke mcp__cua_repl.js with this code:
let tab = await cua.createBrowserTab("chrome", "about:blank", { sessionName: "🧪 Chrome 扩展测试" });- The tool returned the timeout after 30.0480 seconds. Stop at failure; do not navigate to a website.
Restarting, reinstalling the extension, and testing in a new task had already been completed. Existing records were collected without another reproduction.
What is the expected behavior?
Create an about:blank tab and return its initial state, or return a specific actionable error indicating the failed stage.
Additional information
Existing log excerpts (UTC, 2026-09-12):
09:28:37.543Z [AppServerConnection]: server=cua_repl status=ready, for the reported task.
09:28:50.839Z [browser-use-iab-api]: IAB getInfo request completed for the same task and turn.
09:28:50.840Z–09:28:50.842Z [browser-use-iab-api]: repeated getInfo failures: "No ChatGPT browser route is available for browser session 01a094c1-4408-7ae2-ad71-48fc1bbceeab". Stack excerpt: ensureBrowserUseSessionRoute → getInfo.
09:29:20.390Z [browser-use-pip]: Received Browser Use PiP metadata backend=chrome browserID=2 tabID=undefined, for the reported task.
Evidence limits:
- MCP ready does not prove every runtime initialization stage completed.
- IAB events share the task, turn and time window, but causation is unproven.
- PiP metadata does not prove extension receipt or tab creation.
- Extension-side request/response records have not been obtained. Missing log entries do not prove an event never occurred.
Previously recorded Chrome version: 152.0.7977.83; ChatGPT extension: 1.26.901.11451. These and the app/OS versions were not independently verified at the exact failure timestamp.
Please correlate the feedback/task/turn/tool call IDs to determine whether the Chrome request was dispatched, whether the extension received it, whether tab creation completed, whether the response returned, which operation remained pending at timeout, and whether the IAB route failures belong to this call's execution path. No root cause or engineering escalation has been confirmed.
Please use existing evidence rather than repeating restart/reinstall/new-task suggestions or recommending broader permissions without supporting evidence.
Activity
github-actions commentedon Sep 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
dcmf6kms8k-cpu commentedon Sep 12, 2026
Additional read-only findings:
The current unified-computer-use plugin is 26.908.40834.
Its cua_repl manifest has env_vars=[] and no explicit proxy variables. However, the installed @oai/cua-repl launcher copies its own environment when spawning node_repl. This layer does not explicitly remove proxy variables.
Actual Desktop → cua_repl → node_repl environment propagation remains unverified: process inspection was blocked by the sandbox, and permissions were not expanded.
Could maintainers clarify:
No configuration changes, extension retests, or application restarts were performed during this inspection. Proxy handling remains a hypothesis, not a confirmed cause.
dcmf6kms8k-cpu commentedon Sep 12, 2026
Additional diagnostic evidence:
Browser selection succeeded:
cua.getBrowser({id:"chrome"})
Duration: 6.8892 seconds
Selected browser: Chrome, type extension, ID 1.
Reusing that browser handle, this isolated operation failed:
await chromeDiagnostic.nameSession("🧪 Chrome 命名步骤验证");
Duration: 34.7918 seconds
Exact error:
js execution timed out; kernel reset, rerun your request
No tab creation or website navigation was attempted in this isolated test. The inspected desktop log window did not contain the earlier IAB getInfo routing error.
Correlation details:
Feedback ID: 01a08f35-4ae1-7d73-a0e3-fbcc35d2deba
Task ID: 01a094c1-4408-7ae2-ad71-48fc1bbceeab
Turn ID: 01a09563-d8b4-7f23-86ae-f31a1be2dc4d
Tool call ID: call_3Cl9gsTyR1r29Fgopke9kx6s
UTC: 2026-09-12 11:32:32.508–11:33:07.305
Please map this tool call to the internal JSON-RPC request ID and check:
The exact blocking stage remains unconfirmed. Restarting the native bridge process did not resolve the failure. Application restart, extension reinstallation, and new-task testing have already been completed.
dcmf6kms8k-cpu commentedon Sep 12, 2026
Additional investigation of the installed browser-service.mjs found that nameSession can await caller identity and request-header policy initialization before sendRequest is reached. This is a conditional code path; the actual branch taken by the failed call is not yet known.
Please first confirm whether this failed call reached sendRequest:
If it was not dispatched, please check the getInfo agentRequestHeaderEnabled value, caller identity loading, Statsig initialization/update, and request-header policy resolution.
If it was dispatched, please map it to the JSON-RPC request ID and trace native-host receipt, extension processing, and response delivery.
The native host currently directs stderr to /dev/null, and a system-log query for that process during the failure window returned no entries. This does not prove that the request was never received. Could you provide a supported diagnostic logging switch or build that records stages, timing, and request IDs without tokens, identity responses, or page content?
This is a hypothesis from static inspection, not a confirmed root cause. Restart/reinstall/new-task tests have already been completed. No policy checks were disabled or installation files modified during this investigation.
a854008884-ship-it commentedon Sep 15, 2026
I can reproduce the same issue on ChatGPT Desktop 26.908.70816 on macOS / Apple Silicon.
cua.getState() consistently times out with:
js execution timed out; kernel reset, rerun your request
Additional observations:
The in-app browser itself can visibly open webpages normally.
cua.getState() fails even before navigating to a webpage.
The issue persists after a full Mac reboot.
I reproduced it in a completely unrelated new Codex project, so it is not project-specific.
The problem started after updating the desktop app on September 15, 2026.
This strongly appears to be a Computer Use / browser automation control-layer regression rather than a website or project issue.
a854008884-ship-it commentedon Sep 15, 2026
Additional diagnostic evidence from the same reproducible issue.
Environment
macOS 26.5 (Build 25F71)
ChatGPT Desktop 26.908.70816
Bundled Codex runtime: codex-cli 0.154.0-alpha.6.2
Feedback IDs
Initial feedback: 01a0a536-b5d1-7ec2-b438-e5f140b6798f
Latest feedback/session: 01a0a541-f715-7043-8d5f-62451a7d90e2
The issue reproduces in fresh unrelated tasks and affects both @browser and @chrome.
Exact error:
js execution timed out; kernel reset, rerun your request
Additional isolation already completed:
No pending Computer Use approval.
Integrated terminal remains responsive (git status succeeds).
Screen Recording and Accessibility are enabled.
Chrome browser connection/extension was reinstalled and both Chrome and ChatGPT were fully restarted.
The failure still reproduces after those steps.
The matching session transcript records the failing Computer Use operation as:
server: cua_repl
tool: js
plugin: unified-computer-use@openai-bundled
backend: chrome
status: failed
duration: approximately 30.05s
The attempted operation was:
cua.createBrowserTab("chrome", "https://example.com", ...)
Immediately before the timeout, the matching desktop app log contains repeated:
No ChatGPT browser route is available for browser session 01a0a541-f715-7043-8d5f-62451a7d90e2
Near the end of the failed call it records:
Received Browser Use PiP metadata backend=chrome browserID=1 tabID=undefined
OpenAI Support asked me to attach the matching app log and session transcript to the Codex GitHub report because /feedback does not support file attachments.
I have attached redacted/public-only copies of both files. The originals were not uploaded.
app-log-public.zip
session-transcript-public.zip
a854008884-ship-it commentedon Sep 15, 2026
Additional finding:
The bundled plugins are present and enabled locally even though Chrome no longer appears in the desktop Plugin Marketplace UI.
codex plugin list reports:
browser@openai-bundled — installed, enabled — 26.908.70816
unified-computer-use@openai-bundled — installed, enabled — 26.908.70816
chrome@openai-bundled — installed, enabled — 26.908.70816
computer-use@openai-bundled — installed, enabled — 1.0.1001067
However, the desktop Plugin Marketplace no longer shows Chrome and searching for it returns no result.
This suggests the bundled plugin files are present, while the desktop marketplace / registration / browser-session routing state may be inconsistent.
a854008884-ship-it commentedon Sep 16, 2026
Chrome transport is healthy. The failure occurs before nameSession reaches extension RPC, inside the signed node_repl authenticated-fetch host path. authenticatedFetch("https://chatgpt.com/backend-api/aura/identity") never returns a host result; its AbortSignal fires at 10s, but the official Promise remains pending until the ~30s JS kernel timeout. The likely blocking subpath is getAuthStatus / access-token acquisition before HTTP send.
ai-jiaqian commentedon Oct 3, 2026
Adding a separate, limited reproduction from October 2, 2026 on a Mac mini M4 using local Chrome control through cua_repl in a dot-dispatched desktop task.
Recorded sequence:
js execution timed out; kernel reset, rerun your requestTab creation/navigation was not confirmed. Page-title/body reading, link clicking, navigation verification, screenshots, and mouse/keyboard actions were not reached or tested. These were timeouts, not an explicit permission denial.
The app installation was recorded as 26.928.40906 (build 12694) before reinstalling; the exact browser-tool failure-time build was not independently captured. After reinstalling, the Mac mini app version was verified as 26.930.21537 (build 12776), but the follow-up task no longer exposed cua_repl/js_repl. Consequently, the browser test could not run after reinstalling. I am not claiming that the newer build reproduces the timeout or that reinstalling fixed it.
This adds the same error during local Chrome tab creation and URL-based recovery, without establishing the same underlying cause as this issue's original report. We did not obtain extension-side dispatch/response diagnostics. Please advise a supported way to determine which initialization/dispatch stage timed out and why the browser tool was unavailable in the later task. No private tabs, personal paths, account details, task IDs, or full logs are included.