Repository navigation
# In-app browser renders pages but agent control times out #46137
Description
Report status: Prepared locally. Not submitted.
Environment
- Date: 2026-09-17
- Running application: ChatGPT desktop, Codex task experience
- Operating system: macOS 26.5.2, build 25F84
- Application version: 26.903.61454, build 8378
- Browser: built-in browser (IAB)
- User reports that the same Supabase workflow previously worked.
Problem and impact
The built-in browser loads and displays webpages, but the agent cannot reliably acquire the tab, read its rendered state, or control it. This blocks an established Supabase data workflow. The failure also reproduces on the public OpenAI Developers website, so it is not limited to Supabase or an authenticated database page.
Reproduction observed
- In a fresh Codex task, request a visible in-app browser tab for https://developers.openai.com/.
- The createBrowserTab call reports:
Timed out waiting for tab 1 to navigate to https://developers.openai.com/.after approximately 52 seconds. - A subsequent browser inventory nevertheless lists the tab with title
OpenAI Developersand the correct URL. The user-visible browser context also reports this URL. - Acquiring the existing tab with getTab times out. The final test reported
js execution timed out; kernel reset, rerun your requestafter approximately 73 seconds. - Reopening the existing browser panel and navigating back to the task did not restore control in this test.
Related Supabase failures were observed in both the original task and a newly created continuation task. The continuation task could read Supabase through a separate browser, providing counterevidence to a database outage.
Expected result
Once a visible page is loaded, the agent should be able to acquire the tab, inspect its rendered state, and perform authorized interactions.
Relevant sanitized application log evidence
The following entries are from the same running application session on 2026-09-17. Times are UTC. Task IDs and temporary IDs have been replaced with placeholders.
05:53:50.500 browser_use_iab_backend_startup_ready sessionId=<current-task>
05:53:50.536 IAB_LIFECYCLE reassigned browser use route sourceConversationId=<current-task> targetConversationId=client-new-thread:<temporary-id>
05:53:51.485 received browser sidebar owner sync conversationId=client-new-thread:<temporary-id> ownerRoutePath=/local/<current-task>
05:55:53.600 iab backend info request failed: No ChatGPT browser route is available for browser session <current-task>
05:58:20.842 iab createTab mapped page to tab conversationId=<current-task> routeKey=1:client-new-thread:<temporary-id> tabId=1 webContentsId=11
05:58:21.067 iab backend request failed: No target available; request=executeCdp:Emulation.setFocusEmulationEnabled
06:01:06.284 iab backend info request failed: No ChatGPT browser route is available for browser session <current-task>
An earlier Supabase attempt in the same application session also logged:
05:31:33.134 Timed out running CDP command "Emulation.setFocusEmulationEnabled" for tab 5
Assessment and uncertainty
The observations point to an application-side IAB session routing or control attachment failure. The mismatch between the actual task ID and a retained client-new-thread route is a concrete lead for investigation, not a proven underlying code defect. The exact trigger and whether a particular update introduced the regression remain unconfirmed.
Fresh tasks, another website, and reopening the panel did not resolve the failure. A full application restart has not been tested during this investigation. No browser data was cleared, no permissions were broadened, and no database changes were made for this diagnosis.
Requested investigation
Please investigate the route mapping and CDP target lifecycle when a temporary client-new-thread conversation becomes a persisted Codex task. Please advise whether there is a known fix, an available application update, or a supported way to reset the browser control session without deleting website login data.
Activity
github-actions commentedon Sep 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
DreamBorn-999 commentedon Sep 17, 2026
Additional Windows reproduction with both in-app browser and Chrome control affected.
Environment:
Observed behavior:
cua.listTabs({browser:"chrome"})and the documentedbrowser.tabs.list()interface fails withnodeRepl.fetch request failedor a tool timeout/kernel reset.The user reports failure in new conversations as well. A full Windows restart was completed; subsequent tool tests still failed. Resetting the tool JavaScript session and reopening the task did not restore control.
Read-only checks found the computer-use helper running, browser native pipe startup marked ready, and Chrome native messaging registration pointing to an existing extension-host executable. Some IAB metadata requests succeed, so this is not evidence of a completely unavailable service. A system proxy is enabled with localhost/127.* exclusions; its relevance remains unproven.
Expected: browser control can list tabs, read page state, and perform authorized interactions after restart.
The IAB routing error is confirmed, but we have not established whether the Chrome fetch failure has the same root cause. No browser profiles, credentials, firewall, proxy settings, or application data were changed. Please advise on a supported recovery path or fixed build.
jt10191 commentedon Sep 21, 2026
Additional macOS reproduction on September 21, 2026, with desktop app version 26.915.31945, build 9922 (
com.openai.codex).The in-app browser displays a signed-in website, but the agent cannot bind or inspect the displayed tab. After a full app restart, explicit
@Browserselection, and opening a fresh tab, the documentedgetTabcall timed out after 20 seconds and reset the tool kernel. A single read-onlycua.getState()call in a separate existing task also timed out after approximately 30 seconds without returning UI state.Selected application errors:
The user checked for an app update and reports that none is available. Ordinary website sign-in and its separate management API work. No terminal command was sent, and no website credentials, browser data or access settings were changed during diagnosis.
The missing-route symptom matches this issue. We have not established whether the native computer-use error has the same cause.
Is there a supported way to restore the browser control route without deleting website sessions, or a fixed desktop build? No raw logs, task identifiers, credentials or private page content are included here.