Terminal CLI @Browser fails with "The browser access host is unavailable" after desktop app update 26.1023.6123.0 (Windows 11, Brave)

What version of Codex CLI is running?

0.164.0

What subscription do you have?

Pro

Which model were you using?

No response

What platform is your computer?

Windows 11

What terminal emulator and version are you using (if applicable)?

pwsh

Codex doctor report

not available

What issue are you seeing?

Regression on Windows 11 with Brave, affecting browser access from the terminal CLI. Desktop app chats still attach to Brave tabs successfully. Possibly related to #56873.

Terminal CLI @Browser worked on 27 October 2026 with:

CLI: 0.164.0
Desktop app: 26.1021.3705.0
Bundled plugins: 26.1021.31345

It stopped working on 28 October, after the desktop app auto-updated to 26.1023.6123.0 and bundled plugins updated to 26.1023.50603.

Running @Browser list my open Brave tabs from the terminal now fails with:

The browser access host is unavailable

The failure occurs in browser-service.mjs. The runtime environment has BROWSER_USE_ACCESS_EXECUTOR_ID set, but both BROWSER_USE_ACCESS_PIPE_PATH and BROWSER_USE_ACCESS_VERIFYING_IDENTITY are missing. This appears to leave the CLI attempting to use the browser access host without the required connection information.

What steps can reproduce the bug?

Windows 11, Brave, desktop app 26.1023.6123.0, bundled plugins 26.1023.50603, CLI 0.164.0.
From the terminal CLI, run @Browser list my open Brave tabs.
It fails with The browser access host is unavailable.

Tried, none restored terminal browser access:

Rolling the CLI back to 0.164.0
Fully uninstalling and reinstalling both the desktop app and CLI
Starting the CLI with --no-daemon
Overriding env_vars

What is the expected behavior?

Terminal CLI @Browser attaches to Brave tabs, as it did before the update and as desktop app chats still do.

Additional information

The same Brave setup continues to work in desktop app chats. Could you investigate whether the app/plugin update changed how browser access host connection information is passed to terminal CLI sessions, and provide a supported recovery procedure?

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Browser automation unavailable: “The browser access host is unavailable” #56928

Powered by Codex Action

Additional reproduction on Windows 11 with Google Chrome, using the same desktop/plugin versions as this report:

Desktop package: 26.1023.6123.0; bundled plugins: 26.1023.50603.
CLI base version: 0.165.0.
Chrome extension and native messaging manifest checks pass. The extension host runs in interactive Windows Session 1.
The generated unified-computer-use launcher runs Node with --import .../require-browser-access.mjs, followed by @oai/cua-repl/bin/cua-repl.mjs.
That generated import contains process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";.
The manifest declares the executor ID, pipe path, and verifying identity in env_vars, but an ordinary CLI process on this machine inherits none of them. cua.getState() consistently returns an empty browser list and The browser access host is unavailable.

The installed browser service checks whether the executor ID is present (not whether it is nonempty), then requires both the access pipe and verifying identity. This appears to explain why the generated empty executor ID enters access verification with no host connection details. It does not establish the intended authorization policy for standalone CLI clients.

Useful controlled distinction on the affected machine: the same installed Chrome extension and current plugin version work through the bundled Chrome plugin's documented setupBrowserRuntime() interface via the existing node_repl server. We opened a disposable localhost page, typed into its input, clicked its button, verified the changed result, and closed the tab. No browser runtime files or authorization checks were patched. This narrows the difference to the tool launch/context rather than the extension transport or website.

We also inspected a second Windows machine where CLI agents still work: desktop package 26.1021.3705.0, plugins 26.1021.31345. Its generated unified launcher has no require-browser-access.mjs pre-import. This is a version comparison, not a controlled downgrade test.

In the Rust MCP launcher, configured env_vars are already forwarded when present; absent values are omitted. We found no evidence that adding these names to another allowlist would create the missing host address, verifier, or session registration.

Could maintainers clarify the intended standalone-CLI authorization bootstrap for this generated plugin? Is a desktop-managed thread/session handoff required, or should the app expose an authenticated browser-host attachment mechanism for CLI sessions? We are looking for a mitigation that preserves the new authorization check rather than stripping the import, fabricating connection identity, or changing browser security settings.

Additional reproduction from a T3 Code-hosted Codex session on Windows.

Environment:

T3 Code Desktop/server: 0.1.4-nightly.20261028.3824
Windows x64, OS version 10.0.26300
Bundled unified-computer-use plugin: 26.1023.50603

Reproduction:

Run await cua.getState();.
Native application discovery succeeds and lists running Microsoft Edge and Vivaldi windows.
Browser discovery returns browsers: [] and Browsers: Error: The browser access host is unavailable.
Run await cua.getBrowser({ id: "edge" });.
It returns The browser access host is unavailable.

The installed plugin launcher pre-imports require-browser-access.mjs, which sets an absent executor ID to an empty string. Its MCP configuration requests the executor ID, access pipe path, and verifying identity through env_vars.

This confirms the failure in another host application. It does not establish that T3 drops these variables or that environment forwarding alone would restore authorized access.

Could maintainers clarify the supported browser-access bootstrap for third-party codex app-server hosts?

Related T3 discussion: pingdotgg/t3code#26102

No configuration, plugin files, or authorization checks were changed.

Investigated with Codex, model gpt-6.1-sol, via T3 triage.

Additional Windows CLI reproduction after aligning both client and managed app-server versions:

User interface: Codex CLI in PowerShell / Windows Terminal.
CLI, installed managed daemon, and running app-server all report 0.165.0-alpha.1.2 after codex app-server daemon update --from-cli --yes was run outside the Codex tool session.
Bundled unified-computer-use plugin: 26.1023.50603.
A fresh await cua.getState() initializes successfully and enumerates native applications, but returns browsers: [] and Browsers: Error: The browser access host is unavailable.
The user reports that a separate desktop Codex chat successfully read the URL and page title of the public JustWatch Japan homepage. The desktop route was not independently inspected from the CLI.

This rules out client/daemon version mismatch as the sole explanation in this reproduction. We have not proven where the browser host metadata is lost. No plugin launchers, environment values, browser permissions, or authorization checks were modified to bypass this error.

What is the supported bootstrap or attachment procedure for browser access from a standalone CLI session with this plugin? Is an authenticated host handoff required, and if so, how should a CLI user perform it while keeping the interaction in the CLI?

Also affects us on macOS (Apple silicon). Desktop app 26.1023.x, bundled plugins 26.1023.50603, Codex CLI / app-server 0.165.0. It fails in both codex (TUI/exec) and in an app-server host (T3 Code, which spawns its own codex app-server over stdio). Inside the ChatGPT desktop app it still works.

Findings:

It's the preload. The plugin's cua_repl server starts with --import …/require-browser-access.mjs. That file only does process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "". browser-service.mjs skips the browser-access check only when that variable is null/undefined. Setting it to "" forces the check, which needs BROWSER_USE_ACCESS_PIPE_PATH / BROWSER_USE_ACCESS_VERIFYING_IDENTITY. Only processes the desktop app spawns get those, so every other host fails with "The browser access host is unavailable".
Removing the import works. We ran the same server command/env without the --import pair, with env_vars still forwarding the three BROWSER_USE_ACCESS_* variables. Both the CLI and the app-server host could then list and drive Chrome again, and desktop-app sessions kept working.
You can't fix this in ~/.codex/config.toml. A user-level [mcp_servers.cua_repl] override does take precedence over the plugin's registration. But on every launch the desktop app sends config/batchWrite with mcp_servers.cua_repl → null (mergeStrategy replace), which deletes it. An override in a higher layer than the user file survives, for example /etc/codex/config.toml or a managed-config fragment.

If the access check is meant to be strict, it would help to have a supported way for non-desktop hosts (CLI, app-server clients) to get the access pipe/identity. Failing that, the check could be skipped when the desktop app isn't the parent. Either way, the app should stop deleting user-level cua_repl overrides.

Additional macOS reproduction with a directly inspected working desktop control (2026-10-29).

Environment

macOS 27.2 (26B123), arm64.
ChatGPT desktop app 26.1023.50603, build 22391.
Standalone Codex CLI 0.165.0.
Bundled unified-computer-use plugin 26.1023.50603.
Desktop and standalone CLI share the same CODEX_HOME.

Observed behavior
The desktop session successfully controlled Chrome through the extension: opened Google, typed a search query into the page's search field, submitted it, and verified the results.

In the independent CLI, the supplied mcp__cua_repl.js tool starts but await cua.getBrowser({ id: "chrome" }); fails with:

The browser access host is unavailable

cua.getState() likewise returns:

{
  "browsers": [],
  "errors": ["Browsers: Error: The browser access host is unavailable"]
}

The user reproduced this in a real model turn using the stock standalone CLI launched directly from macOS, outside the original third-party host/wrapper. Restarting the desktop app and host, and upgrading/restarting the CLI, did not resolve it. The standalone reproductions were performed and reported from the CLI; the working desktop process/configuration comparison below was independently inspected from the desktop session.

Desktop-versus-CLI comparison

Both use the same app-bundled Node, the same --import .../require-browser-access.mjs, and the same @oai/cua-repl/bin/cua-repl.mjs, from the same generated plugin configuration.
Both currently running desktop-owned cua_repl processes inherit nonempty BROWSER_USE_ACCESS_EXECUTOR_ID, BROWSER_USE_ACCESS_PIPE_PATH, and BROWSER_USE_ACCESS_VERIFYING_IDENTITY.
In the failed standalone CLI process, all three were absent from its launch environment.
The shared plugin manifest lists those names in env_vars, but contains no static values for them.
The desktop authorization socket exists, is owned by the current user with mode 0600, and is listened on by the desktop app. Thus a working authorization host exists for the desktop route; the independent CLI lacks its access context.

Read-only implementation observations
The installed desktop code creates the local App Tools authorization service and an Ed25519 signing identity, injects the socket and public verification identity, and tracks session-to-executor mappings. The working MCP processes use the native-browser-plugin executor marker, which the desktop resolves through that session mapping.

The installed browser service checks access before dispatching each browser command. Its request includes executor, session, turn, and nonce; the response is signature-verified. Missing host path or verification identity produces the reported error before Chrome connection. Separately, desktop code writes the launch configuration into the shared plugin cache.

This supports a host/bootstrap or configuration-scope problem, rather than a failed Chrome extension connection in this reproduction. It does not establish whether standalone CLI access is intended to be supported, nor whether manually forwarding environment variables would be sufficient.

Could maintainers clarify the supported authorization bootstrap for standalone CLI/app-server clients? If this MCP is desktop-only, it should be scoped accordingly or return an actionable unsupported-host diagnostic when discovered by an independent CLI. If standalone CLI access is supported, please provide the authenticated host/session attachment procedure.

No plugin files, authorization checks, or browser security settings were changed during these checks. No tokens, environment values, socket paths, account/session identifiers, private URLs, raw logs, or application source dumps are included. No earlier working CLI version or controlled downgrade was established for this macOS case.

Reproduced from the Codex extension in Visual Studio Code on Windows with Brave (not the terminal CLI). Sharing in case it helps narrow things down; no reply needed.

Environment

OS: Windows 10
Codex Desktop app: OpenAI.Codex_26.1023.6621.0 (bundled plugins 26.1023.51421)
Codex VS Code extension
Browser: Brave, with the ChatGPT extension installed and enabled
Browser permissions: default navigation/downloads set to "Always allow", full CDP access enabled

Symptom
Asking Codex from VS Code to use the browser fails with:

The browser access host is unavailable

[Desktop app chats can still reach Brave: yes / no – à compléter]

What looks healthy locally

com.openai.codexextension.json exists in %LOCALAPPDATA%\OpenAI\extension\, points to an existing extension-host.exe, and lists both ChatGPT extension IDs in allowed_origins.
chrome-native-hosts-v2.json has a single entry for app version 26.1023.51421, and the nodePath runtime folder it references exists.
~/.codex/browser/config.toml is as expected (approval_mode = "never_ask", full_cdp_access_enabled = true).

One observation (not a root cause)
In browser-service.mjs (both the chrome and browser plugins), this error is thrown when either of these environment variables is missing from the process running the session:

BROWSER_USE_ACCESS_PIPE_PATH
BROWSER_USE_ACCESS_VERIFYING_IDENTITY

So the failure seems to happen before any connection to the extension or native host is attempted. That would be consistent with the other reports in this thread, where a session started outside the Desktop app doesn't inherit the connection variables. I haven't confirmed that this is what happens with the VS Code extension; I only read the plugin scripts and did not change any files or settings.

This looks related to #56928 and #57815.

Additional Windows/Chrome reproduction on October 29, 2026.

Browser automation worked October 28, then failed after a desktop/runtime update with “The browser access host is unavailable” and an empty browser inventory.

Desktop runtime: 26.1023.51421; Windows package: 26.1023.6621.0. Chrome native-host registration checks pass. Desktop logs show browser/native listeners starting successfully. Browser/app restarts, a fresh chat, automation reset and a full PC reboot did not restore access.

Feedback reference: no-active-thread-01a187b5-9aea-7b71-8b69-3175bafb505c

Additional controlled macOS reproduction with bundled plugin 26.1023.51421.

Environment: Apple silicon, macOS 26.7.2; ChatGPT desktop app 26.1023.51421 (build 22530); T3 Code 0.1.4-nightly.20261028.3824.

A desktop Codex session successfully opened a public page through cua.createBrowserTab("chrome", ...) on the same machine today. This was verified from its actual tool result, not inferred from Chrome being open.
Standalone CLI 0.164.0 and 0.165.0 both fail on await cua.getBrowser({ id: "chrome" }); with The browser access host is unavailable. We repeated both tests with --no-daemon; both still fail. The installed plugin was held constant, and no global CLI downgrade was performed.
The T3-hosted session fails with the same error. Native desktop control through cua.getApp("com.google.Chrome") works, including navigation and screenshots.
Working desktop-owned browser runtimes have nonempty BROWSER_USE_ACCESS_EXECUTOR_ID, BROWSER_USE_ACCESS_PIPE_PATH, and BROWSER_USE_ACCESS_VERIFYING_IDENTITY. The inspected T3 browser runtimes have an empty executor ID and absent pipe/verifying-identity variables.
The installed plugin manifest preloads require-browser-access.mjs, which sets process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "". The browser service treats the empty string as an enabled access check, then throws when the pipe or verifying identity is absent, before attempting the Chrome connection.

This reproduces the problem with the newer plugin and shows that reverting only CLI 0.165.0 to 0.164.0 does not resolve it with this plugin. It does not prove that T3 drops environment variables or establish the first affected plugin version.

Is there a supported authorization bootstrap/attachment mechanism for standalone CLI and third-party app-server hosts? No authorization checks, plugin files, or browser permissions were changed during these tests.

Additional cross-host macOS MCP reproduction, to distinguish target-host authorization from a local standalone-CLI launch.

The task executes on Mac A (Desktop / bundled plugin 26.1023.51421). An authenticated SSH stdio MCP relay launches the unmodified official CUA on Mac B (bundled plugin 26.1023.50603), preserving its official command, arguments, pre-import and caller metadata.
From that A-hosted task, await cua.getState() returns an empty browser inventory and The browser access host is unavailable.
The same B installation works through a B-local Desktop task: a disposable page was read, its link clicked, the resulting page verified and the test tab closed while preserving all pre-existing tabs.
Presence-only inspection of the actual B processes shows the Desktop-managed runtime has all three BROWSER_USE_ACCESS_* launch variables, while the SSH-launched runtime has none. No values are included here.
We corrected a separate custom argv-validation bug and an unsafe custom SSH-session eviction policy. Those corrections preserve the official pre-import / access checks and do not supply the missing target-Desktop authorization. The direct cross-host browser call still fails.

Please include this cross-host case in the supported-bootstrap guidance: can the target Desktop authorize the true current session/turn of an MCP caller whose task remains on another host, without moving that task to the target host? If so, what supported target-Desktop registration/attachment interface should the relay use? If that direct mode is unsupported, an explicit boundary would help distinguish a missing setup step from a removed capability.

We have not removed the pre-import, unset authorization variables, borrowed another task's context, or exported the generic Desktop authorization socket. No credentials, socket paths, task IDs, hostnames, IPs, private URLs, raw logs or application-source dumps are included.

Codex WSL
Still failing: the Chrome connection timed out at 127.0.0.1:9222 again. I can’t see or control your Chrome tabs from this session yet

Call codex in windows
The browser access host is unavailable.

Codex desktop
works fine

Adding another Windows reproduction. On the same machine, extension-backed Chrome access works in a Codex Desktop chat, but Chrome tab discovery fails from the standalone npm Codex CLI 0.166.0.

Desktop: Windows package OpenAI.Codex 26.1029.7803.0, bundled Computer Use 26.1029.61003. After restarting the desktop app, Codex successfully opened a Chrome tab and read the page.
Standalone CLI: Started codex exec directly from PowerShell, outside the external launcher and without inheriting desktop browser authorization context. A read-only cua.getState() call failed with The browser access host is unavailable. The external launcher reported the same error.

Could the Codex team prioritize restoring extension-backed Chrome access for standalone codex exec? If this workflow now requires a desktop-authorized session, a documented, supported handoff for external launchers would be very helpful. Thanks.

Subject: Windows Codex CLI browser-host failure and a verified alternative initialization path — request for contribution acknowledgment if used

Hello,

I investigated a browser connection failure in Codex CLI on Windows and would like to share both the confirmed failure condition and an alternative initialization path that worked in the same CLI session.

1. Environment

Windows 10 Pro, build 19045
Codex CLI 0.166.0, launched from PowerShell
Codex desktop Windows package 26.1029.7803.0
Bundled browser, Chrome, and unified computer-use runtime 26.1029.61003
Chrome extension installed and enabled

On the same computer, Chrome access worked from a desktop Work conversation but failed from the independently launched CLI.

2. Failure and unsuccessful troubleshooting

Browser discovery and Chrome tab access through mcp__cua_repl.js immediately returned:

The browser access host is unavailable

Selecting Edge produced the same error. The failure occurred before accessing a page.

Reconnecting or restarting the app, running as administrator, restarting Chrome, and retrying the CLI after closing the desktop app did not restore access.

codex doctor --json reported successful installation checks, configuration parsing, desktop app-server initialization, HTTP connectivity, and WebSocket connectivity. However, it warned that browser-access environment variables were missing.

3. Confirmed failure condition

Presence-only inspection of the CLI and its own child cua-repl processes found these variables absent:

BROWSER_USE_ACCESS_PIPE_PATH
BROWSER_USE_ACCESS_VERIFYING_IDENTITY

In the child cua-repl processes, BROWSER_USE_ACCESS_EXECUTOR_ID was present but empty. No environment variable values or credentials are included in this report.

Read-only inspection of the installed browser-service.mjs showed that missing access-pipe or verifying-identity information triggers this exact error before connecting to the access host.

This establishes the immediate failure condition in my environment: the CLI-launched browser tool did not receive the required browser-access connection information. It does not establish why that information was missing or the intended standalone CLI support policy.

4. Verified alternative path

Following a related community report, I used the existing mcp__node_repl__js tool to initialize the installed official Chrome client through its exported setupBrowserRuntime() function.

The initialization was:

var chromeRuntimeModule = await import(
"C:/Users//.codex/plugins/cache/openai-bundled/chrome/26.1029.61003/scripts/browser-client.mjs"
);

var chromeRuntimeAgent =
await chromeRuntimeModule.setupBrowserRuntime();

console.log(await chromeRuntimeAgent.browsers.list());

This JavaScript runs inside the existing Node REPL tool; it is not a PowerShell command.

In the same CLI conversation, I then verified:

Discovery of extension-backed Chrome and Edge
Listing existing Chrome tabs
Claiming an existing FlareDrive tab using its exact returned tab object
Reading its title and live DOM
Reading the displayed file listing

Edge page access was not tested. The phpMyAdmin tab was identified in the tab list, but its page content and database were not read.

No authorization values were copied or fabricated. No security checks, runtime files, registry entries, firewall settings, Defender settings, or persistent configuration were changed. Chrome remote debugging was not enabled.

This did not repair the original cua_repl failure. It demonstrated that browser functionality worked through a different initialization path using the installed official client. I am not claiming a universal fix or confirmed official support for this usage.

Related existing report:
openai/codex #57641

5. Requested investigation

Please review:

The difference between the failing CUA initialization path and the working Chrome-client path.
Whether a supported standalone CLI bootstrap exists for browser-access authorization.
Whether unsupported host contexts could receive a clearer error and documented guidance.
Whether the verified alternative path can be officially supported or incorporated into a product correction.

6. Request for contribution acknowledgment

If the diagnostics, reproduction, or verification in this report contribute to your investigation or a product change, could you please email me confirming that contribution?

If possible, please include the relevant issue, change, or release reference and identify my contribution using my name or report ID.

I referenced existing community reports and do not claim to be the original discoverer or sole person responsible for resolving this issue. My contribution is the failure analysis and successful reproduction of the alternative path in my own environment.

Although this may be a relatively small item among your development priorities, a factual acknowledgment would represent an important professional contribution for me. It would allow me to accurately document this work and report it to my employer as part of my professional record.

I would appreciate acknowledgment limited to the contribution you actually validate and use.

Thank you.

Reproduced on macOS 27.0, Apple Silicon, ChatGPT 26.1029.61003 (build 24614), bundled Codex 0.166.0-alpha.6, and T3 Code 0.1.5. Extension-backed Chrome worked in this setup a few days ago. The original cua.getBrowser({id:"chrome"}) now fails with ‘The browser access host is unavailable’. Chrome is running, native-host registration passes, and its helper is active. The app-generated launcher enables browser-access verification, while the T3-origin session lacks the required desktop authorization context. The installed experimental app-server schema exposes no browser-host attachment method. Please provide a supported repair or fixed release. No access checks were modified and no credentials or private browser data are included.

— Codex

@BC-0217

@BC-0217 Thanks for sharing this. I can confirm that the workaround in your comment also works for me on macOS with Codex running inside T3 Code, using the installed official Chrome client version 26.1029.61003.

The normal cua_repl connection still returned The browser access host is unavailable. In the same conversation, initializing browser-client.mjs through setupBrowserRuntime() inside the existing mcp__node_repl__js tool successfully connected to my existing Chrome profile.

We verified listing existing tabs, opening and reading a temporary page, clicking a link and confirming navigation, and then closing the test tab. We also claimed an existing local configurator tab and successfully changed several options, which I could see updating in Chrome. I subsequently tested the method in a new T3 conversation and it worked there too.

No vendor files, security checks, browser permissions or browser-host identities were changed. This confirms the alternative connection works in my setup; the original cua_repl error remains. Thanks again.

The newer desktop app introduced browser access authorization initialization, but standalone Codex CLI did not reliably receive the required executor identity, host pipe address, and verification identity, causing plugin connection failures. Browser skills also failed to load consistently into CLI sessions, even when the plugins appeared enabled.

Additional Linux reproduction: Omarchy / Arch Linux x86_64, standalone Codex CLI 0.166.0, app-bundled browser runtime 26.1029.61003.

The user explicitly authorized posting this sanitized reproduction. This adds a Linux case and an isolated CODEX_HOME test to this existing report.

Observed behavior

In the standalone CLI, the supplied browser tool returns:

await cua.getState();

{"apps":[],"browsers":[],"errors":["Browsers: Error: The browser access host is unavailable"]}

The user reports that Chromium remains accessible from the ChatGPT desktop app. That desktop success is a diagnostic comparison, not a resolution of the requested CLI workflow.

Historical evidence on this machine

Read-only examination of retained local tool records found successful browser discovery and page creation in a terminal-origin session on November 4 at 20:08 UTC (17:08 BRT). The same conversation recorded the host-unavailable error at 23:22 UTC (20:22 BRT).

The desktop package update from 26.1027.51404 to 26.1029.61003 occurred at 21:19 BRT, after the first observed failure. That update therefore cannot explain the initial interruption by itself. The exact trigger remains unproven.

Controlled tests

Restarting the shared daemon did not restore access. Process inspection confirmed that both the daemon and its MCP children were recreated.
Closing T3 Code, fully terminating and reopening the desktop app, and restarting the CLI did not restore access. This does not rule out an earlier persistent change, but T3 running is not required for the current failure.
A standalone codex --no-daemon session returned the same error.
The user created a new private CODEX_HOME with an empty working directory, authenticated separately using file-based credential storage, and confirmed that codex mcp list initially showed no configured servers. The normal home, session database, plugin cache, and user configuration were not copied into this environment.
A separate profile was then prepared in that isolated home, registering only cua_repl against the existing app-bundled runtime. The CLI recognized the profile. It preserved the generated authorization-marker shell wrapper and forwarded all three BROWSER_USE_ACCESS_* names; no host identity values were supplied or copied from a working session.
The first test-profile attempt failed with CUA_REPL_ENABLED_SURFACES is required because the manually prepared profile omitted NODE_REPL_UNTRUSTED_ENV_ALLOWLIST. That test-setup defect was corrected to match the generated launcher: CUA_REPL_ENABLED_SURFACES,CUA_REPL_BROWSER_ENV.
After restarting the isolated CLI with the corrected profile, the user reported the same JSON host-unavailable error shown above.

The isolated test uses the existing app-bundled binaries; it is not an independent desktop installation or a test against a different runtime version. System-wide policies were not removed.

Local findings and limits

Presence-only inspection of the original processes found the three authorization variables populated in the desktop server and relevant desktop-owned MCP children, but absent or empty in the standalone daemon and its MCP children. The isolated child environment was not independently inspected.

The installed browser service throws this exact error when its authorization pipe or verifying identity is absent, before connecting to that pipe. The installed desktop code also maintains a session-to-executor mapping; an unknown native-browser session is denied. The public app-server JSON schema generated from CLI 0.166.0 with experimental methods included exposed no browser-host attachment method among the 276 method strings collected. This does not establish that no other supported integration exists.

codex doctor outside the agent sandbox passed installation, authentication-configuration, provider HTTP and WebSocket checks, while reporting missing optional MCP environment variables.

Requested guidance

Please provide a supported authenticated host/session bootstrap for standalone CLI sessions, or identify a fixed release. If this app-managed integration is intentionally desktop-only, please scope the tool appropriately or return an actionable explanation instead of exposing a browser tool that fails during discovery.

No authorization check was disabled, no session or executor identity was fabricated, and no working desktop authorization context was injected into the CLI. No browser security settings were changed. No alternative browser controller was installed as part of this reproduction. This report excludes credentials, account identifiers, private tab data, raw transcripts, and user-specific filesystem paths.

Additional Windows reproduction, checked on November 5, 2026.

Standalone Codex CLI: 0.166.0.
Desktop package: 26.1029.7803.0; browser runtime: 26.1029.61003.
ChatGPT Chrome extension: 1.26.1102.11740.

Calling await cua.listBrowsers() from the CLI immediately returns The browser access host is unavailable, before tab discovery or navigation.

The generated launcher forwards the three BROWSER_USE_ACCESS_* variables, but the CLI diagnostic environment has none of them. The browser service requires an access pipe and verifying identity when the executor variable is present. This is consistent with a missing host context; it does not establish whether CLI access is intentionally restricted.

We also checked the current official x64 MSIX: its signature is valid, but its version and application code match the installed package. No authorization checks were disabled during this investigation.

What is the supported authenticated bootstrap or attachment procedure for standalone CLI sessions? If this is a regression, which release restores it? We need to retain the CLI workflow and existing access checks.

Additional macOS reproduction: historical CLI success and working desktop control

External-browser access previously worked from standalone Codex CLI on this Mac and now fails in a fresh CLI session, while a fresh desktop task can still list Chrome tabs.

Observed version history

October 27: retained tool records show originator codex-tui, CLI 0.164.0, successfully opening an external-browser tab and returning rendered page content.
By November 3: CLI 0.166.0 returns “The browser access host is unavailable”.
November 5 reproduction: desktop 26.1029.61003 and Chrome running; standalone CLI 0.166.0 fails, normal desktop task succeeds. Desktop bundles CLI 0.166.0-alpha.6. The exact browser-plugin version used by the historical successful CLI call is unknown, so the introducing release is not established.

Reproduction

Run the desktop app and Chrome normally.
Start a fresh standalone CLI session with the computer-use plugin available.
Ask it to list available browsers without opening or changing anything; the tool calls await cua.getState().

Actual: native-app inventory succeeds, but browser inventory returns:
{"browsers":[],"errors":["Browsers: Error: The browser access host is unavailable"]}

Control: the same read-only request in a fresh normal desktop task lists Chrome tabs. The historical successful CLI call used an external browser; this report does not claim the in-app browser worked from CLI.

Relevant diagnostics

Chrome extension/native-host manifest checks pass.
codex doctor reports BROWSER_USE_ACCESS_EXECUTOR_ID, BROWSER_USE_ACCESS_PIPE_PATH and BROWSER_USE_ACCESS_VERIFYING_IDENTITY missing for the configured node_repl server. This is not a direct observation of the failing cua_repl child’s environment.
Working desktop browser-tool processes descend from the desktop through its bundled codex process and have those three variables populated. Bundled and standalone CLI binaries have the same signing identifier and OpenAI Team ID; a signing-identity difference is not established.

Separate experiment, not the normal reproduction
A temporary shared-daemon configuration successfully initialized transport and exposed a desktop-created task, but browser discovery failed with “native pipe closed before response”. During that call, the desktop logged dynamic_app_tools_peer_rejected reason=untrusted-process-ancestry. Installed source routes browser/access through that native app-tools pipe and also requires session-to-executor registration. The experiment was rolled back and normal desktop browser access was verified afterward. This supports an integration/trust-boundary problem in that topology; it does NOT prove the original missing-host error has the same cause.

Request
Please route this to the desktop/browser-runtime integration owner. Is standalone CLI external-browser access still supported, and what authenticated host/session attachment path should it use? Which component should supply that context while satisfying native process trust and session registration? Environment-variable forwarding alone has not been shown sufficient.

Acceptance
A fresh standalone CLI session can list external-browser tabs and navigate a public test page, desktop access continues to work, and unknown/revoked sessions remain denied. No native authorization checks should be weakened.

No root cause or introducing commit is claimed. A separate remote-controller enrollment prototype did not restore browser access and is excluded from this reproduction; its failures are not evidence for the original regression.

Note

Written by Claude Opus 5.5 on behalf of the account posting it.

Additional Linux confirmation with Brave. The node_repl workaround posted earlier in this thread works here too, and this version survives plugin updates, so I'm sharing it as a reusable skill.

Environment: Linux x86-64, Codex CLI 0.167.0, ChatGPT desktop app and bundled plugins 26.1103.32239 (apt), Brave with the ChatGPT extension.

Result:

mcp__cua_repl.js still fails with The browser access host is unavailable.
setupBrowserRuntime() inside mcp__node_repl__js connects to Brave from a Codex session in T3 Code.
Checked with a temporary tab: navigate, read the page, click a link, confirm the new page, take a screenshot, close the tab.
A fresh Codex session found the skill below and connected to Brave using it.
No plugin files, auth checks or environment variables were changed.

Two details that differ from the earlier snippets:

chrome/latest is a link to the current plugin version, so the path doesn't need a version number. I saw this on Linux and macOS, but ran it on Linux only. Windows isn't checked.
process isn't defined in node_repl, so process.env.HOME fails. homedir() from node:os works.

Requirement: node_repl has to be available as an MCP server. Here it's in ~/.codex/config.toml as [mcp_servers.node_repl].

This doesn't fix cua_repl, and it may stop working in a later update.

To install it, save this as ~/.agents/skills/codex-browser-extension/SKILL.md:

---
name: codex-browser-extension
description: Use my real browser (Brave, Chrome, Edge) through the Codex Chrome extension from Codex CLI or T3, where the normal cua_repl route fails with "The browser access host is unavailable". Use when asked to use my browser in a Codex session.
---

# Codex browser extension

The normal `cua_repl` route needs a Desktop connection that the CLI and T3 don't have. Use `node_repl` instead.

Main report: https://github.com/openai/codex/issues/57641. If it's closed as fixed, try the normal route first.

## Connect

Run this in the `mcp__node_repl__js` tool, not in a shell. Set `wanted` to the browser I named. Run it once per JS session, then reuse `agent` and `browser`.

```js
const { homedir } = await import("node:os");
const { setupBrowserRuntime } = await import(
  `${homedir()}/.codex/plugins/cache/openai-bundled/chrome/latest/scripts/browser-client.mjs`
);
const agent = await setupBrowserRuntime();
const wanted = "Brave";
const found = (await agent.browsers.list()).filter(
  (b) => b.type === "extension" && b.name === wanted
);
if (found.length !== 1) throw new Error(`${wanted}: ${found.length} matches`);
const browser = await agent.browsers.get(found[0].id);
nodeRepl.write(await browser.documentation());
```

Read the returned documentation before doing anything else.

## Rules

- `process` doesn't exist in `node_repl`. Don't use it.
- Say which browser and profile you connected to (`name`, `profileName`).
- Read the page again before each click. Element numbers change with each state.
- Close the tabs you opened.
- Two matches means two profiles: ask me which one.

## When it fails

- Requested browser isn't listed: tell me. Don't switch to another browser.
- No `node_repl` tool or no plugin: tell me what's missing.
- Never edit plugin files, auth checks or `BROWSER_USE_ACCESS_*` variables.

Still a problem because the app-generated launcher requires browser access context that standalone CLI sessions do not have.

Workaround if you're comfortable skipping browser access verification when no executor ID is present:

The generated unified-computer-use/<version>/.mcp.json includes these cua_repl arguments:

"--import",
"file:///.../require-browser-access.mjs"

Copy the server settings, including env and env_vars, into ~/.codex/config.toml as TOML and omit those arguments:

[mcp_servers.cua_repl]
command = 'C:\...\bin\node.exe'
args = ['C:\...\bin\node_modules\@oai\cua-repl\bin\cua-repl.mjs']

Restart the CLI. Verified Chrome navigation and page reading on Windows with desktop 26.1103.4239.0 and plugin 26.1103.32239. The desktop app can overwrite the override on startup.

Edit: You can also simply pick this commit into a fork for yourself JJLiebig#271 it's on purpose very clearly separated from upstream code so should be super simple to use.

codex-desktop: carry external-browser-access from fork

Confirmed on Windows 10 Enterprise 22H2 (x64, build 19045.6456), with T3 Code 0.1.8-nightly.20261108.4380, Codex CLI 0.167.0, and Chrome / unified computer-use plugins 26.1103.32239.

In the same T3 conversation, cua_repl failed with The browser access host is unavailable, while the previously suggested setupBrowserRuntime() entry point from the installed official Chrome client worked through the existing node_repl. Navigation, link clicks, screenshots, tab grouping, and the visible Codex cursor were verified.

No plugin/runtime files, access checks, browser permissions, or BROWSER_USE_ACCESS_* variables were changed. This confirms the existing workaround on this Windows/T3/version combination; the original cua_repl failure remains.

Auto-review by default, --continue, --browser workaround, cheap chang…

Adding an Arch Linux + Google Chrome reproduction, checked November 10, 2026.

Environment

Arch Linux x86_64, kernel 7.2.6-arch2-1.
Standalone Codex CLI and running managed app-server: 0.167.0.
Desktop Arch package: chatgpt-desktop 26.1027.51404-1 (repackaged Linux binary); bundled Codex: 0.166.0-alpha.5.1.
Bundled browser/chrome/unified-computer-use plugins: 26.1027.51404.
Google Chrome: 154.0.8037.57; ChatGPT extension: 1.26.1102.11740, installed and enabled.

Reproduction and working control

In the terminal-origin conversation, await cua.getState(); returns an empty browser inventory with Browsers: Error: The browser access host is unavailable. Browser selection fails with the same error before tab discovery. Starting the desktop app and resetting the CUA REPL did not restore this conversation's browser access.

A fresh desktop fork on the same installation successfully discovered extension-backed Chrome, opened a disposable example.com tab, read its page, and closed it while preserving the existing tabs. This was verified from the actual tool results. The original terminal conversation still fails; desktop success does not resolve the CLI workflow.

The bundled extension-installation and native-host-manifest diagnostics pass.

Immediate failure condition

Presence-only inspection of the actual failing browser worker found:

Variable	State
`BROWSER_USE_ACCESS_EXECUTOR_ID`	Present but empty
`BROWSER_USE_ACCESS_PIPE_PATH`	Absent
`BROWSER_USE_ACCESS_VERIFYING_IDENTITY`	Absent

The generated launcher preloads require-browser-access.mjs, which sets process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";. The installed browser service enters access verification for a present executor variable, including an empty string, then throws this exact error when the pipe or verifying identity is missing, before connecting to the browser. Listing these names in env_vars does not supply the missing context.

This establishes the immediate failure condition here, not the introducing release or intended CLI support policy. No authorization checks were disabled and no working desktop authorization values were copied into the CLI.

Could maintainers provide a supported authenticated bootstrap for standalone CLI/shared-daemon sessions, or identify a fixed release? The desired result is extension-backed Chrome access from the terminal conversation with the existing authorization checks preserved.

@bbrzoska

Note

🤖 Written by Claude (Fable 5.1) on behalf of the issue author. Everything below was run and verified on the author's machine today.

Author update: a fix that keeps `cua_repl` working, survives the desktop app's config rewrite, and leaves desktop chats untouched

Environment: Windows 11 Home 10.0.26300, Brave with the Codex extension, npm Codex CLI 0.167.0, desktop package OpenAI.Codex 26.1103.7773.0, bundled plugins 26.1103.60933. Still broken out of the box on this build, fixed with the steps below.

Verified result: a fresh codex exec from PowerShell used the normal cua_repl tool to open https://example.com in Brave, read the title (Example Domain), and close the tab. Desktop app chats still work as before.

Why this variant

The thread already has two workarounds: removing the --import pair / overriding [mcp_servers.cua_repl] in config.toml (@bbrzoska, @JJLiebig), and bypassing cua_repl entirely by calling setupBrowserRuntime() from node_repl (@andrew-at-v, @BC-0217, @astrovm). Both work, but:

the config.toml override is deleted on every desktop launch by the app's config/batchWrite that sets mcp_servers.cua_repl to null (as @bbrzoska noted), and
the node_repl route means the stock browser tool and skills still fail, so the model has to be taught a side door every session.

Instead, edit the preload itself so it only turns the access check on when the desktop app actually supplied an access host. The desktop app sets BROWSER_USE_ACCESS_PIPE_PATH and BROWSER_USE_ACCESS_VERIFYING_IDENTITY on the processes it spawns, so for those the file behaves exactly like upstream. Any other host (terminal CLI, codex exec, T3 Code, VS Code extension) gets the pre-26.1023 behaviour where the executor ID is left undefined and the service skips verification. Nothing in config.toml changes, so the app cannot undo it at startup.

Steps (Windows paths; same file and edit on macOS/Linux under `~/.codex/plugins/cache/openai-bundled/unified-computer-use/<version>/`)

Back up and replace %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<version>\require-browser-access.mjs. Upstream it is the single line process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";. New content:

// Workaround for openai/codex#57641: only opt into browser-access verification
// when the desktop app actually supplied the access host.
if (process.env.BROWSER_USE_ACCESS_PIPE_PATH && process.env.BROWSER_USE_ACCESS_VERIFYING_IDENTITY) {
  process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";
}

Kill the stale cua_repl. The CLI's managed app-server daemon keeps one cua_repl Node process alive across sessions, and it was launched with the old preload. js_reset does not relaunch it, so a new codex session will still fail until it is gone. The daemon respawns it on demand with the new file:
```
Get-CimInstance Win32_Process -Filter "Name='node.exe'" |
  Where-Object { $_.CommandLine -match 'cua-repl\.mjs' } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }
```
Start a new codex session and ask it to open a page in your browser.
The patched file lives in the version-specific plugin cache folder, so the next app/plugin update replaces it. The script below re-applies it (and -Revert restores the .orig backup):

fix-codex-cli-browser-access.ps1

# Re-applies the terminal-CLI browser-use fix for openai/codex issue #57641.
# Usage:  pwsh -File "$env:USERPROFILE\.codex\fix-codex-cli-browser-access.ps1"
#         add -Revert to put the original files back.
param([switch]$Revert)

$root = Join-Path $env:USERPROFILE '.codex\plugins\cache\openai-bundled\unified-computer-use'
if (-not (Test-Path $root)) { Write-Host "No unified-computer-use plugin found at $root"; exit 1 }

$patched = @'
// Patched locally to work around openai/codex issue #57641 (terminal CLI browser use).
// Original backed up next to this file as require-browser-access.mjs.orig.
if (process.env.BROWSER_USE_ACCESS_PIPE_PATH && process.env.BROWSER_USE_ACCESS_VERIFYING_IDENTITY) {
  process.env.BROWSER_USE_ACCESS_EXECUTOR_ID ??= "";
}
'@

Get-ChildItem $root -Directory | ForEach-Object {
    $file = Join-Path $_.FullName 'require-browser-access.mjs'
    $orig = "$file.orig"
    if (-not (Test-Path $file)) { return }
    if ($Revert) {
        if (Test-Path $orig) { Copy-Item $orig $file -Force; Write-Host "Reverted  $file" }
        else { Write-Host "No backup for $file, left as is" }
        return
    }
    if (-not (Test-Path $orig)) { Copy-Item $file $orig; Write-Host "Backed up $orig" }
    $current = Get-Content $file -Raw
    if ($current -match 'issue #57641') { Write-Host "Already patched $file"; return }
    Set-Content -Path $file -Value $patched -Encoding utf8 -NoNewline
    Write-Host "Patched   $file"
}
Write-Host "Done. Start a new codex session in the terminal for it to take effect."

Second gotcha for Brave (and Edge/Vivaldi/Opera) users

Once past the access gate, the model's first instinct is cua.getBrowser({ id: "chrome" }), and on Brave that fails with:

Browser is not available: chrome

The browser selector in @oai/browser-desktop matches a family name (chrome, brave, edge, ...) only against an extension-backed browser whose reported family is the same, and Brave reports brave. Working selectors here: { id: "brave" }, { id: "extension" }, or { url: "<target url>" }. The bundled chrome plugin's skills/ folder is empty in the plugin cache on this build, so the model gets no hint about this. Putting this in ~/.codex/AGENTS.md fixed it for every session:

## Browser use from the terminal
- The external browser on this PC is Brave. Select it with `await cua.getBrowser({ id: "brave" })`
  (or `{ id: "extension" }` or `{ url: "<target url>" }`). Do not use `{ id: "chrome" }`;
  it fails with "Browser is not available: chrome".
- Then open pages with `await cua.createBrowserTab(browser.browserId, url)` and read them with
  the tab API (`getAXState`, `getScreenshot`, `listTabs`).

Two things that do not help, to save others the time

Editing browser-service.mjs under plugins\cache\openai-bundled\browser\ or ...\chrome\ does nothing for cua_repl. It loads @oai/browser-desktop from the app install (...\app\resources\cua_node\bin\node_modules\@oai\browser-desktop\scripts\browser-service.mjs, read-only under WindowsApps). The cache copies are only used by the node_repl route.
Restarting Brave, the desktop app, or reinstalling the CLI leaves the daemon-owned cua_repl process (and its old environment) alive. Step 2 above is what actually matters.

Trade-off and request

This is explicitly a workaround: sessions not spawned by the desktop app skip the browser-access verification, which is the behaviour every build before 26.1023 had. The CLI's own approval and sandbox settings still apply. It would be great to get either (a) a supported way for standalone CLI / app-server hosts to obtain the access pipe and verifying identity, or (b) the preload shipped with this conditional so that hosts without an access host fall back to the old behaviour instead of a hard failure. Happy to test a build.

Navigation Menu

Repository navigation

Terminal CLI @Browser fails with "The browser access host is unavailable" after desktop app update 26.1023.6123.0 (Windows 11, Brave) #57641

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

30 remaining items

1. Environment

2. Failure and unsuccessful troubleshooting

3. Confirmed failure condition

4. Verified alternative path

5. Requested investigation

6. Request for contribution acknowledgment

Observed behavior

Historical evidence on this machine

Controlled tests

Local findings and limits

Requested guidance

Additional macOS reproduction: historical CLI success and working desktop control

Author update: a fix that keeps `cua_repl` working, survives the desktop app's config rewrite, and leaves desktop chats untouched

Why this variant

Steps (Windows paths; same file and edit on macOS/Linux under `~/.codex/plugins/cache/openai-bundled/unified-computer-use/<version>/`)

Second gotcha for Brave (and Edge/Vivaldi/Opera) users

Two things that do not help, to save others the time

Trade-off and request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Terminal CLI @Browser fails with "The browser access host is unavailable" after desktop app update 26.1023.6123.0 (Windows 11, Brave) #57641

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Oct 28, 2026

JJLiebig commented on Oct 28, 2026

sitenzo commented on Oct 28, 2026

Macchi009 commented on Oct 28, 2026

bbrzoska commented on Oct 29, 2026

Tsutomu-miku commented on Oct 29, 2026

VincentAlb commented on Oct 29, 2026

jmills152 commented on Oct 29, 2026

artpi commented on Oct 29, 2026

komuken commented on Oct 29, 2026

andrew-at-v commented on Oct 29, 2026

30 remaining items

jeffreyhau21 commented on Nov 4, 2026

BC-0217 commented on Nov 4, 2026

1. Environment

2. Failure and unsuccessful troubleshooting

3. Confirmed failure condition

4. Verified alternative path

5. Requested investigation

6. Request for contribution acknowledgment

walkersam1867 commented on Nov 4, 2026

mimeeq-neal commented on Nov 4, 2026

skysbird commented on Nov 5, 2026

tlluiz commented on Nov 5, 2026

Observed behavior

Historical evidence on this machine

Controlled tests

Local findings and limits

Requested guidance

SvechaPVL commented on Nov 5, 2026

sterkenburg commented on Nov 5, 2026

Additional macOS reproduction: historical CLI success and working desktop control

astrovm commented on Nov 7, 2026

JJLiebig commented on Nov 7, 2026

oiBio commented on Nov 8, 2026

RaptorX commented on Nov 10, 2026

vector81 commented on Nov 11, 2026

Author update: a fix that keeps cua_repl working, survives the desktop app's config rewrite, and leaves desktop chats untouched

Why this variant

Steps (Windows paths; same file and edit on macOS/Linux under ~/.codex/plugins/cache/openai-bundled/unified-computer-use/<version>/)

Second gotcha for Brave (and Edge/Vivaldi/Opera) users

Two things that do not help, to save others the time

Trade-off and request

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Author update: a fix that keeps `cua_repl` working, survives the desktop app's config rewrite, and leaves desktop chats untouched

Steps (Windows paths; same file and edit on macOS/Linux under `~/.codex/plugins/cache/openai-bundled/unified-computer-use/<version>/`)