Repository navigation
[Windows][Desktop] Built-in browser route can disappear and saved browser permissions cannot be verified #48670
Description
Summary
On Codex Desktop for Windows, the built-in browser can visibly open pages, but Browser Use can fail when the agent tries to read or interact with the page.
The user-facing error reports that saved browser permissions could not be verified / the browser security check was unavailable.
The desktop logs correlate this with Browser Use route/session failures such as:
No ChatGPT browser route is available for browser session <redacted>
browser use route window missing
route window is not live
This reproduces in fresh conversations and is not tied to one specific website.
Environment
- Windows
- Codex Desktop:
26.924.2738.0 - Codex CLI:
0.158.0-alpha.2.1 - Built-in browser (IAB)
Reproduction
- Open Codex Desktop and start a fresh conversation.
- Open a page in the built-in browser.
- Ask Codex to read or interact with the current page.
- When approval is required, allow the request or configure the origin in Browser agent permissions.
- Browser Use still fails before page content is returned.
In some attempts the visible tab/title can be recognized, while content access still fails.
Actual behavior
The page is visible and usable manually in the built-in browser, but Browser Use cannot reliably attach to/read it.
The UI reports a permission-verification/security-check failure.
The logs show the browser webview/session being created, followed by route/session errors including:
[browser-use-iab-api] iab backend info request failed
No ChatGPT browser route is available for browser session <redacted>
[browser-sidebar-manager] route window is not live
[browser-sidebar-manager] browser use route window missing
Troubleshooting already performed
- Full app restart
- Closed/recreated browser tabs
- Tested in a completely fresh Codex conversation
- Browser enabled in Settings
- Tested Browser agent permissions with approval required
- Tested an explicit allowed origin
- Removed/re-added the origin permission
- Verified there is no Windows User/Machine
CODEX_CLI_PATHoverride - Verified the configured Codex CLI executable exists and runs
- Verified only one
codex.exeis present in the Codex bin directory - No
default_permissions/network.enabled = falserestriction found in config
The issue persists.
Expected behavior
Codex should either:
- use the approved browser origin successfully, or
- display a working approval prompt and then establish a valid Browser Use route.
If the browser route/session is stale or missing, there should be a supported recovery path that does not require deleting unrelated browser/profile data.
Privacy
This report intentionally omits:
- private website/domain names
- project/repository names
- account details
- local usernames/paths
- conversation/session IDs
- credentials/cookies/tokens
- raw logs
I can provide full diagnostics privately to OpenAI support if needed.
Possibly related to #48573 and other Browser Use route/session reports.
Activity
github-actions commentedon Sep 27, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ChinaIceF commentedon Sep 27, 2026
same issue, reinstalling browser plugin doesn't help.
Tasalog commentedon Sep 28, 2026
Additional diagnostic evidence for this issue, reproduced on Windows with both the in-app browser and Microsoft Edge's official ChatGPT extension.
Versions
Reproduction / actual result
The user can manually interact with a local application in the in-app browser.
cua.getState()successfully enumerates that browser and its tabs, as well as the connected Edge browser and its tabs. Bothcua.createBrowserTab(...)and binding an existing IAB tab withcua.getTab(...)fail before page control:No permission request was declined. The readable browser/config.toml contains
approval_mode = "never_ask". This persists after an app restart, a full Windows reboot, user-reported Computer Use reinstallation, connecting Edge with permissions granted, and resetting the CUA REPL before binding the existing tab again.Correlated route evidence
During the latest reproduction at 2026-09-28T10:41:58Z, desktop logs repeatedly record:
Stack entries:
ensureBrowserUseSessionRouteatmain-DAwJoFgo.js:1034:18253, followed bygetInfoat1034:12424.Sidebar owner-sync records associate the visible tab with
conversationId=client-new-thread:<client-id>, whileownerRoutePath=/local/<thread-A>identifies the actual current task. A supportedopen_in_codexrequest to open the existing tab returnsstatus=queuedfor that task. The relationship between this routing inconsistency and the identical Edge permission failure is not yet proven.Permission failure path
Read-only inspection of the bundled browser-service code distinguishes an actual saved user denial from
browser-use-persisted-state-unavailable/approval_unavailable. The latter can be returned when refreshing the saved-permission snapshot throws. That refresh delegates to the runtime'sconfig.readTomladapter. The underlying exception is not included in the observed tool error, so we cannot distinguish a failed configuration RPC from another snapshot-read problem.Potentially relevant installation detail
The standard user
.codexdirectory is an NTFS junction to a custom location on D:. Both paths resolve and browser/config.toml is readable through both, with identical settings. We have not tested a clean non-junction installation, so this is a possible contributing factor, not an established cause. This may be useful when comparing with #35310, but we are not asserting that the full-CDP issue is the same bug.Could maintainers check the permission-read adapter and browser-session routing compatibility in this release, and expose the underlying saved-permission snapshot exception? A supported recovery procedure that preserves permissions and browser data would be helpful.
No application code, security checks, permission settings, or browser databases were patched to bypass the failure. This report excludes credentials, cookies, private URLs, usernames, project names, and raw session identifiers.
Daniconron commentedon Sep 28, 2026
Additional reproduction on 2026-09-28, submitted at the affected user's explicit request.
Environment: Codex Desktop on Windows; version recorded in local diagnostics: 26.924.2738.0; bundled Browser plugin 26.924.22138. Built-in browser (IAB), not an external Chrome session.
In the latest supported Browser API check,
iab.tabs.list()succeeds and returns the correct visible, signed-in tab.await iab.tabs.get('1')succeeds, butawait tab.playwright.domSnapshot()fails before returning page content:Earlier checks in this same affected workflow also failed on a localhost preview. The user has already tried restarting the app, signing into the website again, and closing/reopening tabs; the latest check still fails. The agent has not bypassed the security check or changed browser permission storage.
A prior limited log inspection recorded
No ChatGPT browser route is available for browser session <redacted>in browser-use-iab-api/getInfo. This is correlated evidence only, not a proven cause.Impact: authorized browser-based deployment and end-to-end verification are blocked, even though the user can manually use the visible page. Please provide a supported recovery procedure or identify a fixed desktop build that preserves existing project work, sessions and security controls. Please also distinguish permission-check unavailability from a genuine permission denial in the UI.
Privacy: no private site URLs, store/project names, account identifiers, conversation IDs, local paths, screenshots, credentials, cookies, raw logs or customer data are included.
Arthur-TBL commentedon Sep 30, 2026
Additional Windows IAB reproduction on 2026-09-30, with diagnostics collected by Codex and submitted at the user's request.
Versions: Windows x64; Windows package
26.924.2738.0; app logrelease=26.924.22138.Reproduction: Ask the built-in browser to open
https://example.com/and read its title/body.cua.createBrowserTab("iab", "https://example.com/", { visible: true })timed out;cua.getState()returnedapps=[],browsers=[], andnodeRepl.fetch request failed. The user reports repeated browser reopenings and a fresh chat did not resolve it. We reproduced the inventory failure again, reset the CUA JavaScript kernel, and reproduced it once more.Correlated log evidence (UTC; identifiers redacted consistently):
The second reproduction above was after the kernel reset.
https://example.comwas already in the session's allowed origins. Earlier logs also showed a DOM-ready event for example.com. These requests reached the desktop app and failed its session-route check; the observed error is not simply a failure to load the target website.Narrowed diagnostic hypothesis, not a confirmed root cause: The error stack points to
ensureBrowserUseSessionRoutein bundledmain-DAwJoFgo.js. Read-only inspection indicates this delegates tocanServeSession, which checks backend registration identity, request/backend session matching, and route ownership. The current chat's route/backend had been created, and these failures did not have the companionmissing exact session route ownerwarning. A stale or mismatched backend binding therefore appears worth investigating. We cannot distinguish these branches from existing logs, nor confirm which backend pipe the failing tool actually used.Could maintainers instrument the false-return branches of
canServeSessionwith request session ID, backend session ID, backend registration identity, pending-session count, and route existence, and check the IAB endpoint supplied tocua_replafter temporary-to-permanent chat transitions?Raw logs, account information, local user/project paths, session IDs, and pipe IDs are intentionally omitted. No application files or security settings were modified during this diagnostic.
Daniconron commentedon Sep 30, 2026
Urgent follow-up on 2026-09-30 to #48670 (comment), posted at the affected user's explicit request.
Still reproducible after today's update
OpenAI.Codex_26.928.2636.0_x64(verified from the running executable path).26.928.21956.about:blanktab. Navigation to an explicitly authorized website still fails before page content is returned:A separate automatic-review denial occurred on the first attempt. The user then explicitly authorized the exact destination and read-only test; the subsequent attempt returned the technical saved-permissions error quoted above, not that denial. Please distinguish these two failures.
Timeline and scope
The user reports that extensive built-in browser work succeeded on Friday, September 25, with the same long-standing junction-backed Codex home, and failed on Monday without an intentional configuration change. We have not established the Friday build or root cause. App/PC restarts and subsequent updates have not restored access. Authorized deployment and end-to-end verification remain blocked.
Regarding the community workaround
We reviewed #48573 (comment). Our read-only checks found the current Browser manifest, client and service files present. No separate
chromeplugin directory was found in the inspected bundled-plugin cache, and no matching OpenAI Chrome/Edge native-host registration was found in the inspected user registry locations. The machine-level registry check was inconclusive. This does not establish the stale Chrome registration problem described in that workaround. We have not rebuilt native-host registrations, edited permission stores, removed the home junction or patched browser components.An earlier process-local CODEX_HOME launch trial failed with a package-identity error; its launcher was disabled. It made no persistent environment-variable changes. We need a supported packaged-app recovery method, not direct executable launching or speculative configuration rewrites.
Request to maintainers: Please triage this urgently and provide either (1) a supported diagnostic that identifies the actual permission-snapshot failure, (2) a recovery procedure for the current Windows build that preserves projects, conversations, browser data and existing permissions, or (3) a known fixed build and its rollout status. Is the community native-host repair relevant to an IAB-only installation, and is there an official repair action for it?
This public follow-up contains no private URLs, project/store names, usernames or local paths, account/session identifiers, credentials, cookies, customer data, screenshots or raw logs.
Kackeychang commentedon Oct 2, 2026
Additional reproduction on 2026-10-02, submitted at the affected user's explicit request.
The same permission-verification failure persists on a newer Windows build, including after using Windows' Repair action for Codex and restarting the app.
Environment
26.928.3736.00.159.2; executable SHA256 hashes match26.928.31416Reproduction before Repair
https://x.com/homein the in-app browser and reports that it displays successfully.iab.tabs.list()returns that tab's correct URL and title.tab.ax.write()fails before returning page content:Agent navigation to
https://learn.chatgpt.com/docs/browseralso returned the same class of error. This is not limited to X, and reading an already manually opened page is affected too.Checks and recovery attempts
browser/config.tomlis readable through ordinary filesystem access and containsapproval_mode = "never_ask"anddownload_approval_mode = "never_ask".26.928.31416cache was missing, producing a missingbrowser-service.mjserror. We restored the missing cache directory from the same-version official package bundled with the installed app, keeping older cache directories intact. All 384 copied files matched the source SHA256 hashes. This resolved bootstrap discovery, but not the permission-verification failure.26.928.3736.0.The failing lower-level permission-snapshot exception is not exposed by the observed Browser Use error. We have not established the root cause.
Request
Please investigate the saved-permission verification failure on this build and provide a supported recovery procedure or fixed build that preserves browser data and existing login state. Please distinguish an unavailable permission check from an actual user denial.
This report omits local user/project paths, account identifiers, the user's search query, conversation/session IDs, credentials, cookies, screenshots, and raw logs. Browser security checks and official application code were not patched or bypassed.
swaaswaa commentedon Oct 2, 2026
Additional reproduction observed on October 3, 2026 (UTC+8), posted at the affected user's explicit request.
Environment
26.930.2377.0.26.930.21537.0.159.0-alpha.12.1..codexdirectory is an NTFS Junction to another local drive. Its role in this failure has not been established.Current reproduction
iab.tab.ax.write().The failure persists after the user fully exits and restarts Codex; newly started desktop processes were verified.
Separate bundled-plugin deployment failure
The initial official Browser bootstrap failed because the expected
browser-service.mjscache file was missing. Desktop logs repeatedly showedplugin_marketplace_folder_write_failedandUNKNOWN: unknown error, copyfilewhile copying official bundled-plugin manifests from the installed WindowsApps package into the user marketplace staging directory.A small isolated filesystem probe established:
fs.copyFileof the official package manifest fails withUNKNOWN/ errno-4094.We restored the official bundled marketplace and the same-version Browser cache using byte reads/writes, without modifying official code. All 832 marketplace files and all 384 Browser-cache files matched their respective source SHA-256 hashes. The existing user configuration remained unchanged.
This restored Browser bootstrap and tab discovery, but did not resolve page access. After the app restart, it again attempted bundled-plugin materialization and logged the same native copy failure.
A recent startup log also records:
This is additional diagnostic evidence; its causal relationship to the saved-permission failure is unproven.
Questions for maintainers
The public report omits private website/query details, local usernames and absolute paths, account identifiers, conversation/session IDs, credentials, cookies, screenshots and raw logs. Browser security checks and permission decisions were not altered or bypassed.
swaaswaa commentedon Oct 2, 2026
Follow-up on my earlier reproduction: IAB page access recovered in this environment on October 3, 2026 (UTC+8).
Environment remained the same
26.930.2377.026.930.215370.159.0-alpha.12.1Change made after the failing restart
The user-level
CODEX_HOMEvariable was previously unset. The default user.codexpath is an NTFS Junction to an existing physical directory on another local drive.We set the Windows User environment variable
CODEX_HOMEto that existing physical directory, then fully exited and restarted Codex. The newly started process was verified to have inherited the physical path. This uses the documented CODEX_HOME setting.The original Junction was retained; no data was moved. The configuration file was unchanged by this adjustment. No browser permissions were edited and no security checks were bypassed.
The byte-identical official marketplace/Browser-cache restoration described in my earlier comment had already happened before this adjustment; it had restored bootstrap/tab listing but page reads were still failing. No further cache rewrite or Chrome extension installation was performed for this successful test.
Verified after restart through the official Browser runtime
tab.ax.write().https://example.com/, clicked its “Learn more” link through the accessibility API, and successfully read the destinationhttps://www.iana.org/help/example-domains.cdpcapability andRuntime.evaluate.Networkthrough that capability and received request/response events following the click.The saved-permission verification error did not occur in these tests.
Limits
This is one successful post-restart verification in the environment above, not a claim that the underlying bug is fixed in the product. We have not established a single root cause, long-term/repeated-restart reliability, complete operation recording, or resolution of the separate WindowsApps bundled-plugin copy failure.
This may help narrow the Junction/physical-home path hypothesis also discussed in #48573 and #35310. Can maintainers confirm the intended behavior for a Junction-backed default Codex home and whether the permission/configuration reader should resolve its physical target automatically?
Private local paths, account data, credentials, and session identifiers are omitted.
shuaibitsx233 commentedon Oct 4, 2026
Additional Windows reproduction: tabs are visible, but saved browser permissions cannot be verified
I am experiencing the same issue on Windows. I can open and use websites manually in the in-app browser, but Codex cannot read or interact with them.
Environment
Reproduction
The error is:
No actionable permission prompt appears. Both the main website and its creator platform fail.
Related log messages
Desktop logs contain:
No ChatGPT browser route is available for browser session [redacted]iab backend info request failedroute window is not liveChecks and attempts
CODEX_CLI_PATHoverride exists.Possible filesystem-related lead
The Codex data directory was relocated to D:.
C:\Users\<redacted>\.codexis a Windows Junction pointing to the existing data directory on D:.browserandbrowser\sessionsthemselves are ordinary directories.CODEX_HOMEwas unset in the checked tool process and in User/Machine environment variables.This is only a diagnostic lead, not a confirmed cause. Similar route errors appeared in other chats before the main relocation cutover.
A temporary launcher pointing
CODEX_HOMEdirectly to the physical D: directory has been prepared, but a successful post-launch browser test has not yet been confirmed.Request
Could a developer help distinguish between:
What diagnostic evidence would help identify the underlying failure, and is there a recovery procedure that preserves existing chats, signed-in browser sessions, and saved permission decisions?
ZuyVladislav commentedon Oct 6, 2026
Codex in-app Browser: saved-permissions check unavailable before navigation
Additional Windows reproduction observed on 2026-10-06, submitted at the affected user's explicit request. This report excludes chat history, customer material, local paths, account identifiers, browser profiles, session data and credentials.
Environment: Windows desktop Codex. The configured updater reports installed version 26.930.61225, build 13232, production channel, up to date.
Reproduction: initialize the supported Browser runtime, select the in-app browser, create one temporary tab, navigate to the public page https://learn.chatgpt.com/docs/chrome-extension. Discovery, selection and tab creation succeed. Navigation is denied before page reading:
The temporary tab is closed afterwards. No alternate browser, direct browser-control protocol or security bypass is used.
The global saved-permission configuration passed standard TOML syntax validation. Its SHA-256 was unchanged before/after validation. No configuration values were emitted; no per-session stores were read or reset. This does not establish that every saved preference is semantically valid.
Active Browser client/service match the official files shipped in the installed application. The configured executor paths exist. No supported lower-error diagnostic was found in the documented Browser interface or CLI debug help. The generic error hides whether the underlying reader failed because of a configuration, session-specific, host-injection or other condition. None of those is asserted as a proven root cause.
Request: provide a supported, redacted diagnostic for the saved-permission reader and a correction for the identified cause. Permission checks must remain fail-closed. Acceptance requires ordinary permission-checked navigation/read with existing preferences preserved, not only browser discovery or temporary spontaneous recovery.
Daniconron commentedon Oct 6, 2026
Recovery update, 2026-10-06, shared at the affected user's request. This is a locally verified recovery, not an official fix or a claim that every failure in this issue is resolved.
In this environment, IAB access had recovered on October 4 after setting User CODEX_HOME to the existing physical directory behind the default home Junction and restarting normally, without moving data or changing browser permissions.
Today a separate bootstrap failure occurred: the runtime requested Browser 26.930.41038/scripts/browser-service.mjs, but that version's cache directory was absent; only an older version was present. Installed Windows package: 26.930.4958.0. Its bundled Browser manifest confirmed version 26.930.41038.
With explicit authorization, we restored only the absent version-specific Browser cache from that installed official package using byte reads/writes. All 384 destination files matched their source SHA-256 hashes. Existing cache versions were retained; no application code, configuration, permissions, browser data, or security checks were modified.
The first retry still reported the failed import. After resetting only the JavaScript tool execution environment and initializing the matching official Browser client, the supported IAB API successfully listed existing tabs, read an authenticated page through AX, opened and navigated a new tab, interacted with an authorized non-sensitive form, and captured screenshots. The saved-permission error did not occur during these tests. No app reinstall or data reset was needed.
This distinguishes a missing bundled-plugin cache/bootstrap problem from the earlier saved-permission failure. We have not established why this cache version was absent or whether the recovery persists across future updates. Please investigate reliable materialization of the matching bundled Browser version and handling of cached failed imports.
Privacy: no private URLs, local paths, store/project names, account identifiers, credentials, payment data, session identifiers, screenshots, or raw logs are included.
1823569110 commentedon Oct 6, 2026
Additional Windows IAB reproduction: permissions check unavailable with correlated Cloudflare errors
Submitted at the affected user's request. Reproduced again on 2026-10-07.
Versions and surface
26.930.7945.0(confirmed from the running application).26.930.61225.Reproduction and actual result
tab.ax.write()fails before returning page content:The site origin has been omitted. No recovery or actionable permission prompt is presented.
Correlated diagnostic evidence
The application logs repeatedly classify its user-settings request as:
Other desktop service requests, including conversation and page listing, also show the same error classification. These are normalized, redacted error fields, not an upload of raw logs.
This is correlated evidence, not proof that the Cloudflare response is the cause of the Browser permission-reader failure. The generic Browser error does not expose the underlying failure, and the Cloudflare trigger has not been isolated.
Attempts already completed without recovery
No application code, permission checks, credentials, cookies, or browser-session data were patched or copied to bypass the failure.
Expected behavior / request
Please expose a supported, redacted diagnostic distinguishing:
Please provide a supported recovery flow that preserves saved permission decisions and signed-in browser sessions, or identify a fixed build. Permissions should remain fail-closed; successful tab discovery alone should not be considered recovery.
Privacy: this comment contains no account details, feedback/chat identifiers, target-site or server information, project code, local paths, screenshots, credentials, cookies, or raw logs.
ZuyVladislav commentedon Oct 9, 2026
Recovery follow-up from the same Windows environment as my earlier reproduction, shared at the affected user's request. IAB page access is working again. Two different failures need to be distinguished.
On October 6 we set the Windows User
CODEX_HOMEto the existing physical directory behind the default.codexNTFS junction, kept the junction and all data, and restarted Codex normally. The immediate test before restart still failed. A later fresh initialization of the supported IAB client successfully created a temporary tab, navigated to https://learn.chatgpt.com/docs/chrome-extension, read its accessibility tree, and closed the tab. This was recorded with Windows package26.930.7945.0and Browser26.930.61225. All 384 Browser cache files matched the installed official package. No cache restoration, JavaScript-environment reset, permission reset or security bypass was used for that successful test. We did not isolate which initialization/session change made the permission reader recover.On October 8 we independently identified a reproducible plugin-discovery configuration mismatch.
marketplaces.openai-bundled.sourcestill used the default-home junction alias, while effectiveCODEX_HOMEused its physical target. Both paths reached the same directory. The managed-marketplace path check normalizes Windows device prefixes, separators and case, but does not resolve the junction. The managed source was not recognized and the configured marketplace and associated plugins were filtered out.With the same installed binary, an invocation-only override to the existing physical managed-marketplace path restored discovery of five installed/enabled bundled plugins without changing the configuration. We then backed up the configuration and changed only that source field to the existing
<physical CODEX_HOME>\.tmp\bundled-marketplaces\openai-bundleddirectory. Discovery passed without the override; all other configuration fields remained unchanged. Nothing was installed, moved or deleted.On October 9 ordinary public-page navigation/read worked again, and the user corroborated page loading plus reported reading/link navigation in another existing conversation. The currently installed desktop package is
26.1002.7124.0. This is observed recovery, not an all-chat or future-update stability guarantee.The October 8 path correction demonstrably restored plugin discovery. It cannot explain the first successful page read on October 6, and we are not claiming it universally fixes the original saved-permission exception. Chrome native-host registration is a separate unresolved incident.
For custom-home/junction installations, checking consistency between effective
CODEX_HOMEand the registered bundled-marketplace source may be useful. Please provide a clear diagnostic for this mismatch and a supported way to refresh managed-source registration when the home path changes, while preserving the trust boundary. The underlying saved-permission-reader exception still needs its own redacted diagnostic.Hessamrgzn commentedon Oct 10, 2026
Additional Windows reproduction on 2026-10-10, submitted at the affected user's request.
Current desktop updater result: installedVersion=26.1007.21434, installedBuildVersion=13901, installedReleaseChannel=prod, status=up_to_date.
A website is visibly open in one in-app browser tab. The official Browser client initializes successfully, but agent.browsers.get("iab") returns exactly
Browser is not available: iab. Following the bundled bootstrap-troubleshooting documentation, agent.browsers.list() returns only themcpappsbackend; noiabbackend is listed. This fails before page navigation or a website permission request, distinct from reports where IAB tabs can be listed and permission verification then fails. Repeated documented connection attempts returned the same result. A supported open_in_codex request previously returnedstatus=queueddespite a visible browser tab.The same-version cached Browser client was checked against the installed official Windows package: SHA-256 hashes matched. A backed-up configuration cleanup removed the node_repl MCP section and obsolete browser-client hash override. A subsequent read now finds the node_repl MCP section present again, with a changed native pipe identifier; the mechanism that recreated it is unknown. The obsolete hash override is absent. Thus, removing this section has NOT been established as an effective or persistent fix, and the section should not be assumed to be user-authored. An automatic desktop restart was scheduled, but its completion was not independently confirmed.
Please identify a supported diagnostic/recovery procedure for the missing IAB backend on this Windows build, or a known fixed release. How can users distinguish absent backend registration from stale chat/window routing while preserving conversations, browser profiles, login state and security checks? Is the regenerated node_repl MCP configuration expected, and should native IAB connection metadata be present beyond the Computer Use pipe?
This report omits private URLs, project names, account information, local paths, session/pipe identifiers, credentials, screenshots and raw logs. Official application code and browser security checks were not bypassed.
caralan666 commentedon Oct 17, 2026
补充一例 Windows 内置浏览器复现（2026-10-17）。已获得受影响用户授权提交，仅包含经人工脱敏的诊断摘录。
环境
现象
用户能在内置浏览器看到目标网页，但受支持的 cua.getState() 仅返回空的 MCP Apps 浏览器，未返回 IAB。cua.createBrowserTab("iab", ...) 返回：
通过应用支持的 open_in_codex 打开目标页面返回 queued，未恢复实际页面读取。
脱敏日志证据
以下为日志字段摘录。相同占位符代表相同原始值；省略账号、路径、目标网址、真实聊天/标签/进程/管道标识及堆栈。
随后用户关闭整个内置浏览器面板，保留原聊天，再通过支持的应用工具打开页面。日志出现新的标签 ID，但仍关联同一个临时聊天 ID：
相同错误在随后的 getInfo 请求中继续出现。上述现象支持侧栏与真实聊天的绑定不一致这一诊断假设，尚未确认内部代码根因，也不声称解释了所有 Browser Use 故障。
已实际尝试
没有删除会话或浏览器数据，没有编辑应用代码、修改权限检查、重装插件、直接连接内部控制管道或绕过安全检查。本轮未执行新聊天测试，不将他人报告的步骤算作本轮已验证。
请求
是否有受支持的路由重新绑定/恢复方法，可以保留当前聊天历史、浏览器登录状态和已保存权限？如果需要修复构建，请告知 Windows 对应版本或追踪入口。还需要哪些可以脱敏提供的诊断字段？
验收标准应是同一聊天通过受支持浏览器工具成功读取页面、截图并再次读取，而不只是网页可见、后端 ready、标签列举或 queued。
隐私：本评论未包含真实聊天/会话 ID、本地用户名及路径、目标网站、项目文件、视频内容、账号信息、Cookie、Token、凭据、完整聊天记录、原始日志文件或截图。
awu5425 commentedon Oct 18, 2026
Additional data point reproducing this on a newer build:
Observed: the browser tool starts and lists browsers/tabs normally, but tab binding fails. Logs record the chat browser route as unavailable while the tab reference still points at the temporary chat ID (client-new-thread:<...>) instead of the real route — same routing mismatch signature as described above (conversationId=client-new-thread: vs ownerRoutePath=/local/).
Restarting the app / Windows did not resolve it here either. Happy to provide sanitized log excerpts if useful.
Guan21 commentedon Oct 18, 2026
Additional Windows IAB discovery evidence (read-only; root cause not confirmed)
Environment
26.1013.4894.026.1013.40934Observed behavior
The built-in browser displays web pages, but the agent's browser inventory returns only the MCP Apps provider; IAB is absent.
In one local Desktop log batch for the same anonymized conversation and turn, within approximately 9 ms:
getInforequest failed:No ChatGPT browser route is available for browser session [REDACTED].getInfocompleted successfully, with a returned session ID matching the requested session.getInfocalls failed with the same route error.The same process had previously logged IAB backend startup readiness and successful route capture. These observations do not support treating the backend as permanently unavailable or every route lookup as failing.
Read-only discovery-path findings
Inspection of the installed Browser service indicates that, on Windows, discovery can enumerate candidate browser-use named pipes, call
getInfofor newly connected candidates (default timeout: 5 seconds), and then apply additional processing and filters, including session-scoped identity, optional build-flavor matching, enabled backends, and reuse of cached candidates.The inspected configuration allows
iaband expects build flavorprod. No explicit candidate-path restriction was found in the inspected configuration. This is not a complete snapshot of the running Browser tool's environment.A successful server-side
getInfolog entry therefore does not prove that a candidate was accepted into the final client inventory. The available request logs lack unique discovery/request IDs, candidate pipe or backend-instance correlations, and explicit exclusion reasons. Parallel candidate probes could explain the interleaved successes/failures, but this has not been proven.A
client-new-thread:*identity is not, by itself, evidence of a broken binding. Likewise, anended browser use session activityevent withdisposeAfterSessionActivity=falsedoes not establish that the route was deleted.Other checks / limits
Request to maintainers
Could you provide a supported privacy-preserving diagnostic (or a known fixed build / supported recovery path) that correlates one browser-discovery invocation with:
getInforequest, response, and client receipt;The goal is to restore IAB without deleting conversation history, browser profiles, login state, or saved permissions. This may be related to the discovery observations discussed in #52472, but a shared root cause is not established.
Privacy: No real conversation/session IDs, user or account identifiers, local file paths, private URLs, raw logs, cookies, tokens, or credentials are included.