Repository navigation
[Desktop][Browser Use] No ChatGPT browser route prevents Chrome and built-in browser tab discovery #47270
Description
What version of the Codex App are you using?
26.915.31945, build 9922
What subscription do you have?
Personal workspace.
What platform is your computer?
macOS 26.6.2 (25G83)
What issue are you seeing?
Browser Use cannot discover or control any browser tabs in Codex Desktop. The failure affects both the official Chrome extension and the built-in browser.
Chrome is running, the extension is enabled, Chrome shows Manage in Settings > Computer Use, the correct Chrome profile is selected, and the target site is not blocked. Browser inventory remains empty and the request fails after approximately 30 seconds with:
nodeRepl.fetch request failed
The desktop app simultaneously logs:
No ChatGPT browser route is available for browser session 01a0bd41-0825-7203-b958-ddb89e031363
The visible built-in browser tab is registered under a client-new-thread placeholder while its owner route points to the actual Codex task ID. A newly created Codex task reproduces the same failure.
Native Computer Use is working: it successfully opened macOS Calculator, entered 7 + 5, and read the displayed result 12. This isolates the problem to the browser-session control path rather than general Computer Use permissions or routing.
What steps can reproduce the bug?
- Open Codex Desktop on macOS and start a local task.
- Enable the official Chrome integration in Settings > Computer Use, or open the built-in browser.
- Open a normal webpage in the browser.
- Ask Codex to read or list the current browser tabs.
- Wait approximately 30 seconds.
- Observe that browser inventory is empty and the request fails with
nodeRepl.fetch request failed. - Check the desktop log and observe
No ChatGPT browser route is available for browser session ...during the same request.
The issue reproduces in an existing task and a newly created task, with Chrome and the built-in browser.
What is the expected behavior?
Codex Desktop should initialize a browser route for the current task, return the available browser and tab IDs, and allow the task to operate only its bound tab. Chrome and built-in browser tab discovery should not time out.
Additional information
- Feedback/session ID:
01a0bd41-0825-7203-b958-ddb89e031363 - Chrome: 153.0.8010.53
- Official ChatGPT Chrome extension: 1.26.901.11451
- Chrome plugin: 26.915.31945
- Official extension and Native Messaging checks pass.
- Reinstalling the official desktop app/plugin, restarting the extension host, restarting Chrome, restarting macOS, and testing a fresh Codex task did not resolve the issue.
- The issue reproduces on the original network and a phone hotspot.
- It also reproduces after switching to another proxy node. During the second-node test, connections to
chatgpt.com:443andws.chatgpt.com:443were recorded without matching network, TLS, WebSocket, or timeout errors. - Native Computer Use works with Calculator, confirming the problem is browser-specific.
- Attach
OpenAI支持-可直接粘贴35行-2026-09-22.txtand the diagnostic package to this report.
Activity
github-actions commentedon Sep 22, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gianni77 commentedon Sep 22, 2026
Adding a recurring reproduction on the same app/OS version, with an additional misleading policy-verification error and an intermittent failure during an already working session.
Environment
Observed behavior
The browser is visible and the user can open LinkedIn and sign in. Agent access repeatedly fails across attempts. It briefly recovered sufficiently to read five individual profiles in sequence, then failed again during navigation to the next page. No invitations or messages were sent.
Errors included:
Subsequent normal browser access returned:
This makes the failure appear to be a browser-permission problem. The logs instead provide evidence of a missing browser route, though we have not established the underlying cause or whether it explains every policy-check failure.
Sanitized log evidence
The same missing-route message appeared 11 times for the affected task in the inspected log segment. One occurrence and the immediately following browser-state entries:
The visible tab being associated with a temporary task identifier while requests target the current task appears consistent with the routing mismatch described here. This remains a diagnostic hypothesis.
Recovery attempts and impact
The user reports that this happens frequently and repeatedly interrupts real work. Expected behavior: browser control should remain bound to the active task, or recover through normal app navigation. A missing route should produce an actionable diagnostic rather than only an unavailable admin-policy check.
No browser security checks were bypassed. Personal profile details, account information and task identifiers have been removed from this report.
raon0 commentedon Sep 24, 2026
Additional reproduction on Windows x64, observed 2026-09-24. Posting with the affected user's authorization.
26.917.71314.OpenAI.Codex_26.917.9434.0_x64.cua.getState()andcua.getTab({url: '<open-tab-url>'}, {browser: 'iab'})time out after approximately 20–30 seconds withjs execution timed out; kernel reset, rerun your request.Sanitized log excerpt from 2026-09-24T10:31:08.500Z:
The stack includes
ensureBrowserUseSessionRouteandgetInfo. The error repeats for the current task. Some neighboring getInfo entries report completion, but browser control still times out.Repeated runtime resets and previous app restarts did not restore control. The official
open_in_codexaction returnsqueued, but a subsequentcua.getState()still times out. No cookies or website login data were deleted. A separate Chrome DevTools browser remains controllable; that is not the user's IAB session and does not restore it.Please investigate task-to-IAB route registration/recovery on Windows as well, and provide a supported recovery that preserves website sessions. The precise underlying cause and update that introduced the failure are not established. This report omits email, task identifiers, customer data, local usernames/paths, and full logs.
youdeserveit8 commentedon Sep 24, 2026
Additional Windows reproduction on 2026-09-24, submitted with the affected user's authorization.
Environment: Codex Desktop AppX
26.917.9434.0on Windows x64. The official Chrome extension/native messaging components are present. The built-in browser backend starts and reports availability.New route evidence from the desktop log:
conversationId=client-new-thread:<temporary-id>, whileownerRoutePathpoints to the actual local task.getInfothen fails withNo ChatGPT browser route is available for browser session <current-task-id>.cua.createBrowserTab('iab', 'https://example.com', {visible:false})timed out, but the Example Domain tab was subsequently visible in browser inventory.cua.getTaband latercua.getState()failed or timed out withnodeRepl.fetch request failed.Recovery attempts: resetting the browser tool runtime removed an earlier kernel-asset startup error, but did not restore browser control. Navigating to the current task and opening the browser through the supported Codex UI action returned
queued; a freshcua.getState()still failed. Resetting the browser tool runtime again produced the same result. The issue affects both the built-in browser and Chrome discovery in this task.This appears consistent with a task-to-browser route registration or recovery problem, although the root cause is not confirmed. Please investigate a supported recovery that preserves existing browser sessions. No cookies, browser settings, or app data were deleted.
Task identifiers, local paths, accounts, and full logs are intentionally omitted from this public comment.
ssk797 commentedon Sep 25, 2026
Additional Windows reproduction with a useful recovery boundary, submitted with the affected user's authorization.
Environment: Windows 11 x64 (build 26200), Codex Desktop AppX
26.917.9434.0. The configured app updater reportsup_to_date.cua.getState()reportsnodeRepl.fetch request failed, andgetTab/navigation may time out and reset the tool kernel.getState()followed bycreateBrowserTab('iab', ...). The missing-route failure persists. A full app restart alone therefore did not provide a durable recovery.Sanitized desktop-log evidence from the restarted app:
The task-to-browser route appears to remain attached to the temporary
client-new-threadID even after the real task is active and the app has restarted. Please investigate route reassignment and recovery after tab switching/closing, and return an actionable error instead of a 20–30 second timeout. This comment omits task IDs, account data, local paths, website login state, and raw logs.ssk797 commentedon Sep 25, 2026
Follow-up correction from the affected user and the subsequent dataset-download attempt:
Please consider this clarification when triaging the issue. It contains no task IDs, local paths, account identifiers, or raw logs.
tanghairong commentedon Sep 27, 2026
Title
Browser Use control path times out at 30/60s while Computer Use with Edge works normally
Environment
26.924.2213811645com.openai.codexSummary
Browser Use appears to have a routing / RPC / IPC problem on my Codex Desktop installation.
Browser discovery and lightweight metadata operations are fast, but operations that require actual browser/page control frequently time out after exactly ~30 seconds or ~60 seconds.
At the same time, Computer Use with the same Microsoft Edge installation works normally and completes equivalent browser operations in milliseconds to a few seconds.
This strongly suggests that the problem is isolated to the Browser Use/browser-control path rather than Edge itself, the webpage, or general desktop automation.
Browser Use + Microsoft Edge
Using Browser Use only:
agent.browsers.list()125 msEnumerate Edge tabs using
edge.user.openTabs()30 sA second documented Edge tab-list operation
15 sReading an existing tab URL/title
No navigation or page modification was performed.
Browser Use + Codex In-app Browser
Using only the Codex In-app Browser:
agent.browsers.list()102.6 ms6.3 mshttps://example.com/30.0 s2.7 ms30.0 sNetwork.enable30.0 sThe most interesting case is tab creation:
js execution timed out; kernel reset, rerun your request.4 mshttps://example.com/Example DomainThis suggests that the browser command itself may have completed successfully, but Browser Use did not receive or process the result/acknowledgement before the 30-second timeout.
In an earlier clean IAB test, the following calls eventually succeeded but had very consistent delays:
~2-4 ms~30 sRuntime.evaluate("1+1")~60 sNetwork.enable~60 sRuntime.evaluate("document.title")~30 sRuntime.evaluate("1+1")eventually returned2, andNetwork.enableeventually returned{}.This does not look like a slow webpage or blocked JavaScript execution. The operations eventually succeed, but only after very regular 30/60-second delays.
Computer Use + Microsoft Edge
Using Computer Use only, with Browser Use explicitly disabled:
709 ms244 ms264 ms251 ms1.45 shttps://example.com/~1.7 s70 ms81 ms1.41 s1.10 sComputer Use can successfully interact with the same Edge browser, existing authenticated tabs, new tabs, screenshots, navigation, and visible page content.
Therefore Edge itself and the desktop-level browser integration appear to be healthy.
Relevant Desktop Logs
A full-day audit of the Codex Desktop logs found:
1. Repeated IAB route failures
There are
122occurrences of:They are emitted by
browser-use-iab-apiduringgetInfo, with the stack involving:These occur after Browser Use initialization completed successfully.
2. Native-pipe peer rejection
There are 9 Browser Use native-pipe rejections with:
There is also one related
dynamic-app-toolsrejection.3. Browser sidebar / IPC lifecycle warnings
The logs also contain:
IpcRouterEPIPEerrors4. No obvious browser timeout log entry
I did not find Browser Use log entries containing:
The 30/60-second behavior is visible from actual Browser Use operation timings, but the corresponding timeout does not appear to be logged directly.
Proxy / Network Checks
I also investigated whether a macOS proxy/VPN configuration was responsible.
Direct
curlconnections to:time out after approximately 10 seconds on this network.
Explicitly routing them through the local HTTP/SOCKS proxy at:
returns within approximately
0.25-0.4 s.I then configured
HTTP_PROXYandHTTPS_PROXYin~/.codex/.env, fully quit Codex Desktop, restarted it, and repeated the clean IAB test.There was no improvement:
So proxy inheritance does not appear to explain the Browser Use delay.
Expected Behavior
Browser Use operations such as:
should complete within normal interactive latency when the browser and page are responsive.
Browser Use should also behave consistently with the working Computer Use + Edge path.
Actual Behavior
Browser Use:
Computer Use with the same Edge installation works normally.
Suspected Area
Based on the behavior and logs, this appears related to the Browser Use control path, possibly:
The repeated:
messages appear particularly relevant.
Reproduction
A minimal reproduction using the Codex In-app Browser:
https://example.com/.Runtime.evaluate("1+1")Network.enableRuntime.evaluate("document.title")Typical result:
A comparable test with Browser Use + Edge fails during tab enumeration.
A comparable test with Computer Use + Edge succeeds normally.
Additional Notes
example.com, so it is not specific to my local application.farlantea commentedon Sep 28, 2026
Additional macOS reproduction observed on 2026-09-28, including a fresh-task comparison after an actual app restart/update.
Environment
com.openai.codex.Observed behavior
https://example.comtab in a fresh local task hits the 20–30 second outer tool execution deadline. Subsequent inventory remains about:blank.Unable to capture screenshot. An independent DOM snapshot returns an empty string.Fresh-task routing evidence
The fresh task is significant because its real conversationId matches the task ID in ownerRoutePath. The desktop log records sidebar guest attachment and host page opening for this real task, but subsequently still reports:
The old task showed a client-new-thread placeholder mismatch. That mismatch alone cannot explain this fresh-task failure. The underlying cause remains unproven; an outer tool deadline is not evidence of a website network timeout.
Please investigate browser-route readiness/recovery after guest attachment with a correctly bound durable task ID, and provide a supported recovery that preserves website sessions. Acceptance requires reading a real public page, performing a harmless click and reading the resulting state, then completing the same chain on an authorized authenticated page.
No credentials, cookies, profiles, task history or application databases were deleted. No private protocols, packaged app code, security settings or business settings were modified. This comment omits private URLs, account/business identifiers, task IDs, local usernames/paths and raw logs.
feng-Qinyu commentedon Sep 28, 2026
Additional macOS reproduction on 2026-09-28, posted with the affected user's authorization.
Environment:
Observed sequence:
The relationship between the earlier policy-verification error and the later route failures is not proven. This reproduction does show that removing the stale CLI override and restarting did not restore browser control, and that the failure extends to a fresh task. No browser security check was bypassed, no target-site data was changed, and no account details, private URL, task IDs, or raw logs are included.
Please investigate browser route lifecycle/recovery for this build and provide a supported way to restore Browser Use without weakening its security checks.
mokamal1311 commentedon Sep 29, 2026
Additional macOS reproduction and migration timing evidence (2026-09-29).
https://example.commanually. Agent Browser Use cannot access it. Both the bundled Browser plugin andcua.createBrowserTab('iab', 'https://example.com', {visible:true})fail with: “Browser Use could not complete this action because a browser security check was unavailable. Reason: Browser Use could not request permission. ... saved browser permissions could not be verified.”No ChatGPT browser route is available for browser session <current-task-id>. The browser host/sidebar is associated with aclient-new-thread:<temporary-id>placeholder while its owner route points at the actual local task. This is an observed mismatch, not a proven root cause.up_to_date.Please investigate the task-to-browser route and saved-permission verification path, and provide a supported recovery procedure. I can provide private diagnostics if requested; this public comment intentionally omits user/account IDs, local paths, raw logs, and private URLs.
wwoland commentedon Sep 30, 2026
I am seeing the same missing-browser-route log error on September 30, 2026, with the same desktop app version as this report.
Environment:
An OLX tab was manually opened in the built-in browser, but Browser Use cannot attach to it or create a usable tab. The tool returns:
The desktop log repeatedly contains:
Repeated attempts to attach to the existing tab, create a tab, and reset the CUA runtime did not resolve it. Switching the task to Full Access also did not resolve it. CODEX_CLI_PATH is unset in the command environment and in launchd, so the stale-path workaround does not appear applicable here.
The same policy-verification error also occurred when trying to open community.openai.com to report this bug. This is not limited to OLX in this session.
I have not confirmed the client-new-thread mismatch described above, or that the missing route causes the policy-verification failure; these are the two observed symptoms. Is there a supported recovery procedure that preserves the current task, or a build containing a fix?
Update — September 30, 2026: After fully quitting and reopening the desktop app, the already-downloaded update was applied: 26.917.62051 (build 10789). In the same existing task, Browser Use can now attach to the OLX tab and read its page contents; navigation also works. No browser-policy bypass or permission-file edits were used. This reports recovery in my case only; I cannot separate the effect of the full restart from the version update or confirm a general fix.
alex700 commentedon Oct 3, 2026
Additional macOS reproduction on October 2, 2026, submitted with the affected user's authorization.
Environment:
Observed behavior:
Normal web reading successfully retrieves https://example.com.
cua.createBrowserTab("iab", "https://example.com", {visible:false}) repeatedly fails in under a second with:
Browser Use could not complete this action because a browser security check was unavailable. Reason: The admin-enforced policy could not be verified, so access was not granted.
The same browser error occurs for public postings on Greenhouse, Workday, and Oracle-hosted careers pages. The generic public-page test shows that this is not isolated to one posting.
Resetting the CUA JavaScript session, then initializing a new normal browser call, does not recover access.
Supported navigation back to the same existing chat returns navigated:true, but a subsequent browser call still fails.
The affected user reports encountering this almost daily and restoring access by restarting the desktop app without changing policy. A full restart has not yet been performed in this controlled reproduction.
Sanitized desktop log observations for the affected chat:
2026-10-03T04:17:46.801Z warning [browser-use-iab-api]
IAB_LIFECYCLE iab backend info request failed
conversationId=<CURRENT_CHAT>
errorMessage="No ChatGPT browser route is available for browser session <CURRENT_CHAT>"
request=getInfo
2026-10-03T04:17:46.953Z info [browser-use-iab-api]
IAB_LIFECYCLE iab createTab mapped page to tab
conversationId=<CURRENT_CHAT>
pageKey=1:client-new-thread:<TEMPORARY_ID>:browser-use:<TAB_ID>
routeKey=1:client-new-thread:<TEMPORARY_ID>
After supported navigation back to the existing chat:
2026-10-03T04:18:34.385Z info [browser-use-iab-api]
IAB_LIFECYCLE iab createTab mapped page to tab
conversationId=<CURRENT_CHAT>
pageKey=1:client-new-thread:<SAME_TEMPORARY_ID>:browser-use:<NEW_TAB_ID>
routeKey=1:client-new-thread:<SAME_TEMPORARY_ID>
The missing-route errors and mapping of the durable chat request to a temporary client-new-thread route are observed facts. Their relationship to policy-verification failure remains a hypothesis, not an established root cause.
Expected behavior:
Initialize/recover the browser route bound to the durable current chat ID and successfully perform the applicable policy check. If the route or policy service is unavailable, report that component failure with an actionable recovery path, distinguishing it from an actual policy prohibition. Provide a recovery that preserves chats and website sessions.
No security controls were bypassed and no profiles, cookies, permissions, application code, caches, or databases were modified. This public report omits private posting URLs, candidate information, Drive files, usernames, chat/session IDs, and full raw logs.
Related: #46295 and #46350. This adds a reproduction on 26.930.21537 with normal-web versus browser comparison, unsuccessful CUA reset and supported chat-navigation recovery, and timestamped route-mapping evidence.
alex700 commentedon Oct 3, 2026
Recovery update: after restarting Codex, the in-app browser successfully rendered and exposed readable job descriptions on all five previously blocked public ATS pages (Greenhouse, Workday, and Oracle Candidate Experience). The vacancy analysis and tracker updates then completed successfully.
The app also updated from 26.930.21537 (build 12776) to 26.930.31730 (build 12947) during this restart. This observation does not isolate the effect of restarting from the effect of the update, and it does not establish a permanent fix. No browser warning or security interstitial was bypassed. The previously reported policy-check-unavailable denial no longer occurs in this chat.
runlinx-eng commentedon Oct 6, 2026
Still reproducible on macOS as of 2026-10-06.
I am seeing the same failure pattern as this issue:
No ChatGPT browser route is available for browser session ...client-new-threadtemporary conversation ID, while the owner route points to the actual Codex task ID.This does not appear to be website-specific. The same browser-control failure occurs before any Douyin-specific logic or account verification.
Additional observation: tab identity/metadata can be available while the actual Browser Use control/read route is missing, so the UI can show a working page even though Codex cannot inspect or control it.
Impact: Codex can see that browser tabs exist, but cannot read or control their contents, making Browser Use unusable.
I can provide additional sanitized logs privately if needed.
jackongmusic-ux commentedon Oct 9, 2026
Additional reproduction on a newer desktop build, shared with the affected user's permission. This report is sanitized; account details, website URLs, local paths, session identifiers, screenshots, and raw logs are omitted.
Environment
Observed browser behavior
The user can open and manually interact with pages in the built-in browser, but agent control cannot reliably attach to those pages.
cua.createBrowserTab("iab", ...)andcua.getTab({url: ...}, {browser: "iab"})repeatedly timed out after approximately 30–40 seconds withjs execution timed out; kernel reset, rerun your request.cua.getState()call succeeded but returned an empty app list and an empty built-in-browser tab list, despite a manually visible browser tab. This is a single successful snapshot observation, not a claim that every snapshot call returns empty.Sanitized log observations
Repeated built-in-browser getInfo requests logged:
A createTab mapping in the same diagnostic period showed:
Browser availability was also logged as
available=true browserPane=true.This mapping is an observed diagnostic correlation, not proof of the underlying cause. No evidence was found that the individual websites were refusing automation.
Separate native-control observation
The same installation also logged
Failed to spawn managed Computer Use servicewithcomputerUseEnabled=true(and a later capture-worker failure). Native app APIs were not exposed in the tested runtime. This may be a separate issue; there is no evidence establishing a shared cause with the browser routing failure. Some later snapshot-capture log entries did report success, so this is not a claim that all screenshot capture is broken.Could maintainers confirm whether this browser-route failure is known on 26.1007.21159, and whether there is a supported way to reattach/reset the browser route without deleting conversations, browser profiles, or project data?
conorzhang commentedon Oct 12, 2026
Additional local macOS reproduction on 2026-10-12, still failing after an actual desktop update/restart and Chrome reinstall. Posting with the affected user's authorization.
Environment
arm64).com.openai.codex: 26.1007.30912, build 20156. Installed metadata and fresh startup logs both confirm the updated version is running.Minimal results after the update
cua.getBrowser({id: "chrome"})cua.listTabs({browser: "chrome"}), 30-second tool deadlinenodeRepl.fetch request failed; increasing the outer deadline does not restore access.navigated: true.queued; does not establish usable control.cua.createBrowserTab("iab", "https://example.com", {visible: true})client-new-threadroute.Sanitized, correlated desktop logs (UTC)
The placeholder mismatch and missing-route error are observed facts. Their causal relationship to the Chrome failure and the precise underlying defect remain unconfirmed. I am not treating an IAB log entry as proof of the Chrome transport's root cause.
Recovery attempts already completed
CODEX_CLI_PATHpoints to the existing current app-bundled executable, and the browser-service configuration references 26.1007.30912. No override pointing to a nonexistent app installation was found.Browser profiles, cookies, sign-in state, chat history, and application databases were not cleared. No application-code patch, security-check bypass, or permission expansion was used.
Request
Please investigate durable-chat-to-browser route binding/migration and Chrome control-response delivery on 26.1007.30912 / build 20156, and provide a supported recovery procedure or a build containing a fix.
Acceptance should include returning Chrome tabs and completing a harmless page read/action/readback, plus the equivalent IAB chain. Provider discovery, a manually visible page, or successful native Computer Use alone does not demonstrate Browser Use recovery.
This report intentionally omits account details, local usernames/paths, real chat/session/tab identifiers, private website content, screenshots, and full raw logs.
Leask commentedon Oct 12, 2026
Additional reproduction on October 12, 2026: the built-in browser remains unusable for the affected user after restarting the desktop app. Posting with the user's explicit authorization, including their request to communicate the serious impact on normal work and ask for a prompt fix.
Impact and current status
Browser-dependent development, page inspection, and UI verification are being blocked. The user's external Chrome Beta integration is also unavailable, so switching between these two browser choices does not restore their workflow. The Beta-specific evidence is reported separately in #28584; I am not assuming the two failures have the same root cause.
The user briefly reported that the built-in browser appeared usable after the restart, then explicitly corrected that assessment: it still cannot be used. The fresh desktop logs below reproduce the missing-route signature after the restart. A restart therefore has not established a durable recovery in this case.
Verified environment
com.openai.codex.arm64.26.1007.30912.browser-client.mjsare present. These checks do not support a missing runtime-file explanation.Fresh, correlated evidence
In the restarted desktop process, the affected existing conversation's IAB backend reaches startup-ready, and its browser execution service reaches ready. Later
getInforequests for that same conversation fail with the missing-route error:The inspected post-restart log contains 12 missing-route entries, at four timestamp groups between 16:33:28 and 16:39:41 UTC, all associated with this affected conversation. These are log-entry counts, not 12 independently identified failed operations.
Startup readiness is therefore insufficient to establish that the conversation has a usable browser-control route. This report combines the user's current failure report with correlated desktop diagnostics; it does not invent DOM, screenshot, or page-navigation results from a diagnostic executor that lacks the official browser execution tool.
Investigation and proposed fixes
The exact defect is not isolated. Please investigate the lifecycle between successful backend startup and durable conversation-to-browser route registration/lookup, including route ownership changes on foreground conversation selection and restart.
Suggested acceptance criteria:
client-new-threadroutes, when used during initialization, are correctly transferred to the durable conversation; retries recover a stale or missing route without accumulating duplicate tabs.Please prioritize this as a workflow-blocking browser issue, confirm an engineering owner and affected/fixed builds, and provide a supported recovery that preserves conversation history, browser profiles, and sign-in state. The existing reports and this fresh reproduction warrant a prompt fix rather than repeated restart-only guidance.
No app-bundle patch, native-host installation, permission expansion, security-check bypass, profile/cookie deletion, or conversation/database modification was performed during this diagnostic pass. Local usernames, host/project names, conversation/tab IDs, private URLs, and raw logs have been omitted.
penfoldslin-glitch commentedon Oct 13, 2026
Browser control fails across fresh chats on Windows; durable route reassigned to client-new-thread
Codex Desktop 26.1007.21434, build 13901, production. The supported updater reports up_to_date on 2026-10-13.
Both an existing chat and a freshly created chat fail with the supported browser APIs:
Timestamp-correlated Windows desktop logs for the fresh chat (2026-10-13, UTC+08:00):
Recovery attempts that did not restore control:
These observations implicate IAB session routing but do not prove the Chrome fetch failure has the same cause. No request-header-policy or Statsig cause has been established for this installation.
Please investigate the durable-to-placeholder route reassignment and provide a supported recovery or confirmed fixed build. Please also identify what supported diagnostics can distinguish Chrome bridge failure from the IAB route failure.
Cookies, sign-in state, browser profiles and product files have been preserved. No internal routing database, application bundle or security policy was modified. This report omits account details, local paths, chat/tab IDs, credentials, private URLs and raw logs.
Related public reports:
#47270
#48360
conorzhang commentedon Oct 14, 2026
Follow-up reproduction on 2026-10-14: partial recovery after client update, Browser Use still not stable
Posting an additional sanitized update for the affected user's existing report. This does not open a duplicate issue.
Current result after the desktop client update
Current interpretation
The remaining failure is still consistent with a Browser Use session/route or debugger-target ownership problem, including durable-chat versus temporary
client-new-threadroute identity. The page also showed that ChatGPT had started debugging the browser, and duplicate tabs with the same ChatGPT URL were present. These are correlated observations, not a claim that one specific component is proven as the root cause.The evidence does not support treating this as a generic network outage, a missing Chrome installation, or a missing official extension. Native Chrome Accessibility and ordinary Chrome UI work on the same machine.
Requested acceptance criteria
Please consider the issue fixed only when the official Browser Use path can, on the affected existing conversation:
and when the equivalent built-in-browser/IAB route survives tab creation, conversation switching, and a desktop restart without falling back to an untracked temporary route.
This update intentionally omits account details, local paths, session/tab identifiers, cookies, tokens, private page content, and raw logs.
najafsen commentedon Oct 14, 2026
Additional macOS reproduction on October 14, 2026, posted at the affected user's explicit request to notify the developers.
Environment:
Two distinct failures were observed.
Initial socket permission failure, now repaired:
The machine-global /private/tmp/codex-browser-use directory was owned by another local macOS user with mode 0755. The affected account could not write there. Desktop logs repeatedly recorded browser_use_iab_backend_startup_failed with EACCES: listen permission denied on /tmp/codex-browser-use/.sock. The user applied chmod 1777 to this exact directory. Subsequent inspection confirmed mode 1777 and write access, and logs changed to browser_use_iab_backend_startup_ready. This matches the multi-user collision discussed in Codex Desktop: invalid transport in mcp_servers.codex_app although codex_app is not present in config.toml #40860.
Browser control remains unavailable after that repair:
Correlated sanitized logs:
20:56:32.062Z browser_use_iab_backend_startup_ready sessionId=<UI_CONVERSATION>
20:58:03.847Z received browser sidebar owner sync conversationId=<UI_CONVERSATION> ownerRoutePath=/c/<UI_CONVERSATION>
20:58:18.371Z iab backend info request received conversationId=<AGENT_SESSION> request=getInfo
20:58:18.371Z iab backend info request failed: No ChatGPT browser route is available for browser session <AGENT_SESSION>
<UI_CONVERSATION> and <AGENT_SESSION> are different IDs. Browser startup readiness and visible tab attachment therefore do not establish a usable route for the requesting agent. The identity mismatch is directly observed; the upstream reason that the IDs are not bound is not established.
Impact:
An explicitly authorized signed-in administrative workflow remains blocked before page access. Repeated attempts consume paid usage and require the user to repeat setup without completing the task. Please provide a supported recovery for existing Work conversations and investigate the ChatGPT-conversation-to-agent-session browser binding. The user has explicitly expressed serious frustration with the repeated failures.
No real session/tab IDs, local usernames, private site content, credentials, consent codes, cookies, or raw logs are included. Browser policy and packaged app code were not modified.