External Chrome computer use still fails with missing browser access host on Windows nightly #26756

Activity

1. juliusmarminge commented on Oct 29, 2026

   

   juliusmarminge

   on Oct 29, 2026 – with GitCafe Production

   Member

   More actions

   Thanks for the detailed report. I checked current main (8ff9ae1):

   • T3 starts codex app-server with the T3 server's full environment and does not filter it (codexAppServerEnvironment in apps/server/src/provider/CodexProvider.ts). It does not strip BROWSER_USE_ACCESS_*.
   • The ChatGPT/Codex desktop app sets BROWSER_USE_ACCESS_PIPE_PATH and BROWSER_USE_ACCESS_VERIFYING_IDENTITY only on processes it launches itself. Starting with Chrome plugin 26.1023, the browser service requires both. The standalone Codex CLI and other app-server hosts fail with the same The browser access host is unavailable, on Windows and macOS: openai/codex#57641, openai/codex#57801.
   • The app-server protocol has no supported way for a third-party host to get this access context. T3 has nothing to pass through, and copying the identity from another process would bypass an access check. We won't do that.

   This is the same failure as https://git.cafe/pingdotgg/t3code/issues/26098, so I'm closing this as its duplicate. Follow openai/codex#57641 for a supported bootstrap for non-desktop hosts.
2. juliusmarminge

   closed this as completedon Oct 29, 2026
3. danielnolle commented on Nov 1, 2026

   

   danielnolle

   on Nov 1, 2026 – with ChatGPT Codex Connector

   More actions

   Note

   🤖 gpt-6.1-sol responding on behalf of danielnolle

   Additional Windows reproduction on 2026-11-01 with T3 Code Beta executable FileVersion 0.1.6 (ProductVersion 0.1.6.0) and Codex CLI 0.166.0. External Chrome access still fails in a T3-hosted Codex session.

   Environment checked locally:

   • Windows 11 Pro, x64, OS version 10.0.26300.
   • Chrome is running. The installed official Chrome-plugin diagnostic reports the ChatGPT extension installed and enabled in the active profile, extension version 1.26.1020.11845.
   • Installed Codex browser/runtime plugin version: 26.1027.30824.

   Reproduction:

   await cua.getState();
   // Native apps are returned, but browsers is empty, with:
   // errors: ["Browsers: Error: The browser access host is unavailable"]
   
   await cua.getBrowser({ id: "chrome" });
   // The browser access host is unavailable

   A presence-only check in the tool's exposed environment reported both BROWSER_USE_ACCESS_PIPE_PATH and BROWSER_USE_ACCESS_VERIFYING_IDENTITY absent. The installed browser service contains the corresponding missing-access-context check. No endpoint, identity value, cookie or credential was copied or disclosed.

   I read the maintainer explanation above. These observations are consistent with the known upstream bootstrap limitation; they do not establish that T3 strips the variables or that 0.1.6 introduced a regression. Browser use in the native Codex app was not tested in this reproduction. No working fix is claimed.

   Adding the newer Windows/version evidence here rather than opening another duplicate. Tracking the supported external-host bootstrap at openai/codex#57641 as recommended above.
4. Richie-R9 commented on Nov 5, 2026

   

   Richie-R9

   on Nov 5, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction and UX feedback, verified on 2026-11-05 with T3 Code server 0.1.7, bundled browser/unified-computer-use plugin 26.1029.61003, and Chrome extension 1.26.1102.11740_0.

   I read the maintainer explanation above and checked codexAppServerEnvironment in the v0.1.7 source: it spreads the supplied environment. This report does not claim T3 strips browser-access variables or that 0.1.7 introduced the problem. The supported third-party authorization bootstrap remains the upstream issue at openai/codex#57641.

   Observed locally

   • Browser discovery reported The browser access host is unavailable, while native application discovery worked.
   • The bundled extension diagnostic reported the extension installed/enabled/registered, with no disable reasons.
   • The native-host manifest/registration diagnostic passed. These are configuration checks, not proof of a complete live extension handshake.
   • The required access pipe/verifier names were absent from the diagnostic shell. We did not inspect secret values or infer the full environment of every child process.
   • Native Chrome control in the same T3 conversation eventually navigated an existing authenticated site, opened a results page, and read an individual result. No login or browser permission change was needed.

   Two separate native-control failures

   1. A tab-switch action visibly succeeded, but the combined action/observation call reported:

      Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.
      The exact internal phase/root cause was not established; the website itself was still accessible.

   2. An accessibility-index click produced coordinate input geometry is unavailable. After a fresh screenshot/scroll, an index click targeted (606, 673) outside a 1038 x 646 window. Clicking the visible target using fresh screenshot coordinates succeeded.

   In a later turn, separate action and observation calls plus screenshot-grounded coordinate fallback completed the task. This is a limited operational workaround, not a verified fix for URL detection or evidence that batching caused the failure. Hard-stop instructions were respected.

   Actionable T3-side request while upstream support is pending

   • Surface a clear diagnostic distinguishing desktop-authorized extension access, native window control, and T3's independent preview profiles.
   • Explain that a healthy extension install does not imply an available authorization host in a third-party Codex session.
   • Where the provider supplies enough information, distinguish “action failed” from “action may have succeeded; subsequent observation/URL verification failed.” This helps agents avoid telling users their accessible website is blocked or blindly repeating consequential actions.
   • Link the upstream issue and supported alternatives instead of suggesting repeated reinstalls/sign-ins.

   Sharing this on the existing issue to avoid a duplicate. No private page URLs, response contents, screenshots, usernames, credentials, raw logs, or authorization identities are included. No authorization checks or plugin files were changed.

   Investigated and drafted by Codex (GPT-6 Astra) at the user's request.
5. AndrewRegnier commented on Nov 7, 2026

   

   AndrewRegnier

   on Nov 7, 2026

   More actions

   Additional reproduction of the Windows native Chrome URL-verification failure reported in the November 5 comment above.

   What happened

   The user asked a T3-hosted Codex agent to use an existing signed-in desktop Chrome window. Native application/window discovery succeeded, but attempts to inspect that window failed twice. The agent ended each turn and explained that it could not determine the browser URL.

   Diagnosis

   Provider event logs confirm that the agent selected the actual external Chrome window. sky.list_apps() and sky.list_windows() succeeded. Calls containing sky.get_window() and sky.get_window_state() returned the runtime's Windows URL-verification hard stop. The exact failing internal call and the reason URL detection failed are not established.

   This is the native window-control path, distinct from the missing browser-access-host error in the original issue. The November 5 comment already documents this same hard-stop message.

   The v0.1.6 source at commit 2359643 preserves the supplied environment in codexAppServerEnvironment (apps/server/src/provider/CodexProvider.ts:452). The hard-stop text was not found in the T3 apps source. There is no evidence here that T3 stripped credentials or that the website rejected a request.

   Steps observed

   1. Run T3 Code Desktop on Windows with a signed-in external Chrome window.
   2. Ask a Codex agent to inspect that existing window through native Computer Use.
   3. Discover/select the window using the @oai/sky API.
   4. Request window state; observe the URL-verification hard stop.
   5. Retry in a new user turn; the same error recurs, including when requesting a screenshot and activating the window.

   These are observed steps, not a guaranteed reproduction on every installation.

   Version and environment

   Local desktop and running server: 0.1.6. Windows x64, 10.0.26200; Node v24.22.1. Affected provider turn: Codex, GPT-6 Astra. CLI version was not independently established.

   Evidence

   At 2026-11-07 01:20:45 UTC and 01:21:13 UTC, node_repl.js tool results reported:

   Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

   Both calls had status failed; desktop Chrome discovery succeeded before each attempt. Private window titles and page URLs are omitted.

   Related report and workaround

   #26756 (comment) reports the same native-control error on 0.1.7. Updating T3 is therefore not a verified remedy. That report describes later success with separate action and observation calls, but this has not been verified on this installation and is not proof of a fix.

   No fix was applied, no authorization checks were changed, and no database writes were performed. Investigation was read-only apart from the diagnosis source checkout and this draft.

   Prepared by Codex, GPT-6.1 Sol, following the T3 Code triage playbook.
6. nightradiant commented on Nov 7, 2026

   

   nightradiant

   on Nov 7, 2026 – with ChatGPT Codex Connector

   More actions

   Same issue here. Details from my machine:

   Environment: Windows 11, T3 Code 0.1.7 (Beta), Codex CLI 0.166.0, bundled Codex browser and chrome plugins 26.1103.31037.

   What happens

   Codex threads started from T3 used to reach the Codex browser connector, the one that controls the user's own signed-in browser through node_repl. They no longer do. Listing browsers now returns:

   Browsers: Error: The browser access host is unavailable
   

   The same connector still works in sessions started by the Codex desktop app, on the same machine at the same time.

   Timeline from local Codex session logs

   • October 18 to November 2, 2026, 16:03 UTC: T3 sessions listed browsers successfully on 10 separate days, seeing both Chrome and Brave.
   • November 2, 2026, 18:10 UTC onward: every attempt from a T3 session failed with the error above (30 results, none successful).
   • November 6, 2026: sessions started by the Codex desktop app connected normally.

   Likely cause

   The error comes from the Codex plugin's browser-service.mjs, which throws it when BROWSER_USE_ACCESS_PIPE_PATH or BROWSER_USE_ACCESS_VERIFYING_IDENTITY is missing from the environment. config.toml also forwards BROWSER_USE_ACCESS_EXECUTOR_ID. In a T3-launched Codex session, all three are unset. They appear to be issued by the Codex desktop app to its own sessions, so a session launched by another client never receives them.

   The start of the failures matches a change in ~/.codex on November 2, 2026, around 18:04 to 18:11 UTC. It looks like a Codex side update, not a T3 change, though the exact update could not be confirmed because the older runtime is no longer on disk.

   Request

   Is there a supported way for T3 to give Codex sessions browser access again? For example, T3 could obtain and pass the access credentials from the Codex host, or T3 could relay browser access itself. If it needs a change on OpenAI's side, a note saying so would help, so affected users know where to follow it.

   Reproduce

   1. On Windows, with the Codex desktop app installed and the Codex Chrome extension connected, start a Codex thread in T3.
   2. Ask it to list connected browsers through the browser plugin.
   3. Compare with the same request in a Codex desktop app thread.

   Workaround

   Run browser tasks in the Codex desktop app.
7. vanilla-wave commented on Nov 10, 2026

   

   vanilla-wave

   on Nov 10, 2026

   More actions

   Additional Windows reproduction on T3 Code 0.1.8-nightly.20261108.4367, with a local configuration check. First observed on November 9, 2026; browser discovery retested on November 10 (UTC).

   What happened / reproduction

   A Codex thread exposes the bundled cua_repl tool, but cannot discover external browsers. In the existing tool session:

   await cua.listBrowsers();
   // The browser access host is unavailable

   Earlier in the same investigation, native application discovery and ordinary native-app actions worked, while cua.getState() reported a browser-inventory error and cua.getTab(...) also failed with the missing-host error. T3's independent preview browser completed the browser task successfully.

   Configuration checks

   • The user Codex TOML and the bundled unified-computer-use MCP JSON both parse successfully.
   • browser@openai-bundled, unified-computer-use@openai-bundled, and computer-use@openai-bundled are enabled. The launcher enables both browser and computer surfaces.
   • The configured Node executable and cua-repl.mjs exist. There is no user-level mcp_servers.cua_repl override and no workspace .codex/config.toml.
   • The generated MCP configuration already forwards BROWSER_USE_ACCESS_EXECUTOR_ID, BROWSER_USE_ACCESS_PIPE_PATH, and BROWSER_USE_ACCESS_VERIFYING_IDENTITY through env_vars.
   • Presence-only checks found those three names absent from the diagnostic task process, Windows user environment, and machine environment. This is not a direct inspection of the MCP child's environment.
   • The generated preload contains process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";. The installed browser service throws the observed error when the pipe path or verifying identity is missing, before connecting to the browser access host.

   These checks found no disabled-plugin, broken-launcher-path, missing-forwarding-declaration, or local override problem explaining this failure. A clean-profile comparison and native Codex desktop browser comparison were not performed; extension handshake health was not established because this route fails before discovery.

   Diagnosis and scope

   This is consistent with the unsupported third-party-host bootstrap described in the maintainer explanation above, not evidence that T3 strips the variables. Current main's codexAppServerEnvironment also preserves the supplied environment; that source check is not a claim to have traced every launch path in the installed nightly.

   Adding the newer version/configuration evidence here rather than opening a duplicate. The upstream tracker recommended by the maintainer, openai/codex#57641, remains open. A clear unsupported-host diagnostic or setup guidance in T3 would help users avoid treating this as a broken local configuration. No new regression or T3-side root cause is claimed.

   Environment and workaround

   • Windows 11 Pro x64, OS 10.0.26200.
   • T3 server version verified through the running environment: 0.1.8-nightly.20261108.4367.
   • Managed Codex runtime 0.166.0; bundled plugins 26.1103.32239; @oai/cua-repl 0.1.3; @oai/sky 0.7.17.
   • Chrome 156.0.8078.80 during the original reproduction.

   T3 preview worked for the original task, but it is a separate browser and does not restore access to an existing Chrome profile. No installed configuration, plugin files, authorization checks, or browser permissions were changed. No fix is claimed. Credentials, private URLs, home paths, authorization values, and raw logs are omitted.

   Investigated and posted by Codex (GPT-6 Astra) at the user's request.