# Codex "The browser access host is unavailable": No CLI Fix Yet

> No fix for Codex CLI or IDE sessions as of November 11, 2026: run the browser step in a ChatGPT desktop app chat. In the app or with @Chrome, use OpenAI's checks.

- Source: https://www.aifreeapi.com/en/posts/codex-browser-access-host-unavailable
- Language: en
- Published: 2026-11-11
- Updated: 2026-11-11
- Publisher: AI Free API (https://www.aifreeapi.com)

`The browser access host is unavailable` means Codex's browser tool could not get access to a browser through the ChatGPT desktop app. Where you started the task decides what you can do about it.

If you ran Codex from a terminal, `codex exec`, VS Code, JetBrains, another app built on Codex or an SSH project, stop tinkering locally. OpenAI's own Browser page says the feature isn't available in Codex CLI or the IDE extension, users report that the route they relied on broke after desktop app updates in late October, and as of November 11, 2026 there is no fix and no reply from OpenAI. Do the browser part of the task in a new Work or Codex chat in the ChatGPT desktop app. If the error appears inside the desktop app itself, or when you mention `@Chrome` there, OpenAI's connection checks below are the place to start.

## Where "The browser access host is unavailable" shows up decides the fix

Look at where you typed the request, then pick the row.

| Where you started the task | What is going on | What to do now |
| --- | --- | --- |
| Terminal `codex` with `@Browser` or `@Chrome`, `codex exec`, the VS Code or JetBrains Codex extension, a host app such as T3 Code, Paseo, Orca or Claude Code's Codex plugin | OpenAI documents Browser as unavailable outside the desktop app. Sessions launched elsewhere fail the access check before they reach a browser. | Run the browser step in a new desktop app chat. See [the CLI and IDE section](#codex-cli-exec-and-ide-run-the-browser-step-in-the-desktop-app). |
| A remote project over SSH | Reported to fail the same way, including remote projects opened from the desktop app, while a local desktop chat on the same computer still works | Run the browser step from a chat on your local machine |
| A Work or Codex chat in the ChatGPT desktop app using the built-in browser (`@Browser`) | The app's own session can't reach its browser. Reported on macOS and Windows builds since October 19, 2026. | Update the app, fully quit and reopen it, start a new chat. See [the desktop app section](#the-browser-access-host-is-unavailable-in-a-chatgpt-desktop-app-chat). |
| A desktop app chat using `@Chrome`, `@Edge` or another browser through the ChatGPT extension | The app can't connect to the extension in that browser | Work through OpenAI's extension checklist. See [the extension section](#chrome-and-other-browsers-through-the-chatgpt-extension-openai-s-check-order). |

A quick way to tell the first row from the others: open the ChatGPT desktop app on the same computer, start a new chat and ask it to use the same browser. If that works while your terminal or IDE session keeps failing, you are on the CLI route. Nearly every CLI, IDE and host-app report on GitHub describes exactly that split, for example "[CLI browser control fails … desktop works](https://github.com/openai/codex/issues/59456)" and "[Native @Browser fails … while Desktop Browser works](https://github.com/openai/codex/issues/58916)".

## Status as of November 11, 2026: no OpenAI reply, no fixed version

- **Open reports.** More than 20 separate issues on the openai/codex tracker quote this error, the earliest dating from October 19, 2026 ([#55173](https://github.com/openai/codex/issues/55173)). The largest, [#57641](https://github.com/openai/codex/issues/57641) ("Terminal CLI @Browser fails … after desktop app update 26.1023.6123.0"), had 34 reactions and 50 comments on November 11. All are open except one that was closed as a duplicate of #57641.
- **No answer from OpenAI.** None of these issues has a reply from an OpenAI maintainer. The only non-user comments are automatic duplicate notices from a bot. One reporter wrote that OpenAI's AI-assisted support collected logs and then pointed them to the GitHub issue ([#56928](https://github.com/openai/codex/issues/56928)).
- **No fixed version.** The release notes for Codex CLI [0.167.1](https://github.com/openai/codex/releases/tag/rust-v0.167.1) (November 10) and 0.167.0 (November 6) don't mention browser access, and the [changelog](https://learn.chatgpt.com/docs/changelog) has no desktop app note after 26.1007. Reports from CLI 0.167.0 still show the error ([#60130](https://github.com/openai/codex/issues/60130)).
- **Newest desktop build still fails from the CLI.** A test run on November 11, 2026 used macOS 26.1 on Apple silicon, ChatGPT desktop app 26.1103.60933 (running and signed in, bundled browser plugins at the same version) and Codex CLI 0.166.0. A read-only `codex exec` session asked to call `cua.getState()` once returned:

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

That run did not test a desktop app chat on the same Mac or CLI 0.167.x. It does show that updating the desktop app to 26.1103.60933 doesn't bring back the CLI route.

OpenAI hasn't said publicly whether Codex CLI and the IDE extension will get browser access back, or when. Treat any date you see elsewhere as a guess.

![Timeline from October 19 to November 11, 2026: first issue, #57641 opening, one desktop recovery report, CLI 0.167.0 and 0.167.1 without a browser fix, and a test run that still fails; status card shows 20+ open issues, 0 OpenAI replies and no fixed version](https://www.aifreeapi.com/posts/en/codex-browser-access-host-unavailable/img/status-november-11.webp)

## Codex CLI, exec and IDE: run the browser step in the desktop app

OpenAI's [Browser documentation](https://learn.chatgpt.com/docs/browser) opens with: "Browser isn't available in Codex CLI or the Codex IDE extension. Open the ChatGPT desktop app to use the built-in browser." Several reporters say the terminal route did work until desktop updates in late October ("[Previously working Chrome access now fails](https://github.com/openai/codex/issues/59300)"), but OpenAI's documentation doesn't say whether letting the CLI borrow the desktop app's browser was ever supported. Either way, nothing documented will make it work from the terminal today.

Check in this order:

1. **Confirm the desktop app can still use the browser.** Start a new Work or Codex chat in the ChatGPT desktop app and mention `@Browser`, or `@Chrome` if you need your signed-in browser. If that also fails, fix the desktop side first using the sections below.
2. **Do the browser part of the task in a fresh desktop chat.** Open the same project there and keep the terminal or IDE for the rest. Start a new chat rather than reopening the thread your IDE created: a VS Code user reported that opening the VS Code chat in the desktop app still failed ([#56928](https://github.com/openai/codex/issues/56928)).
3. **For remote and SSH projects, run the browser step locally.** Reports from a Windows-to-Linux SSH setup ([#59925](https://github.com/openai/codex/issues/59925)) and a Linux EC2 project ([#60459](https://github.com/openai/codex/issues/60459)) show the remote session failing while a desktop chat on the host machine works.
4. **If the terminal session itself must drive a browser, use a separate browser tool.** Reporters had Playwright MCP working in the VS Code extension and in CLI 0.166.0 ([#58916](https://github.com/openai/codex/issues/58916)), and Chrome DevTools MCP 1.12.0 with `--autoConnect` listing tabs and reading a page from CLI 0.166.0 ([#56928](https://github.com/openai/codex/issues/56928)). These tools don't use the ChatGPT extension or its site permissions. They have their own, and attaching one to your everyday browser profile gives the agent every session you are signed into there.
5. **Add your details to #57641 and subscribe to it.** It is the largest thread, so it's the one to watch for an OpenAI reply. See [what to include](#reporting-the-browser-access-host-error-versions-to-include).

### Steps reported not to help the CLI route

Users in [#57641](https://github.com/openai/codex/issues/57641) and [#56928](https://github.com/openai/codex/issues/56928) tried all of these and still got the error from the terminal or IDE:

- rolling Codex CLI back to 0.164.0
- reinstalling the desktop app and the CLI
- `--no-daemon`, overriding `env_vars`, a full reboot
- updating Chrome and Codex, restarting, and resetting the computer-use runtime
- starting the desktop app first, then resetting the CUA REPL
- switching models

### Why only desktop-launched sessions pass the access check

This explanation comes from users, not OpenAI. The plugin launcher bundled with desktop app 26.1103.60933 passes three environment variables to the browser runtime: `BROWSER_USE_ACCESS_EXECUTOR_ID`, `BROWSER_USE_ACCESS_PIPE_PATH` and `BROWSER_USE_ACCESS_VERIFYING_IDENTITY`. Reporters who dumped their environment, including with `codex doctor --json` in [#58916](https://github.com/openai/codex/issues/58916), found the pipe path and verifying identity only in processes the desktop app starts. A terminal, IDE or host-app session doesn't have them, so it fails the access check before it ever reaches a browser. That fits the pattern in the reports: the browser and extension are fine, and only the session's origin differs.

![Two lanes: a ChatGPT desktop app chat has BROWSER_USE_ACCESS PIPE_PATH and VERIFYING_IDENTITY set and passes the access check; a terminal, IDE, host app or SSH session lacks both and returns The browser access host is unavailable](https://www.aifreeapi.com/posts/en/codex-browser-access-host-unavailable/img/access-check-by-launch.webp)

### Unofficial patches in the GitHub threads

Several users have posted workarounds in #57641: a `config.toml` override that drops the access-check preload, calling the Chrome plugin's browser setup directly through `node_repl`, editing the plugin preload, and third-party bridge projects. OpenAI endorses none of them. They all skip or get around the browser access check, which is the permission gate between an agent and your signed-in browser. They also don't last: users report that the desktop app deletes the config override every time it launches, and plugin updates replace edited files. If you need something that keeps working, the separate browser tools in step 4 are the steadier choice.

## "The browser access host is unavailable" in a ChatGPT desktop app chat

This is the smaller group, and the one where OpenAI's steps can actually help. OpenAI doesn't publish a checklist for this exact message or for the built-in browser. The app-level steps from its [browser connection troubleshooting](https://learn.chatgpt.com/docs/chrome-extension) cover any desktop chat, in this order:

1. **Update the ChatGPT desktop app.** If more than one ChatGPT or Codex desktop app is installed, update each one or remove the copies you no longer use.
2. **Start a new Work or Codex chat** and try the browser task again. OpenAI notes this "can clear chat-specific connection state."
3. **Restart the ChatGPT desktop app.** Quit it fully rather than just closing the window, then reopen it.
4. **Using `@Chrome` or another external browser?** Continue with the extension checks in the next section.
5. **Still failing?** Run `/feedback` in the app and include the chat ID when you contact support.

One Windows user in [#58856](https://github.com/openai/codex/issues/58856) reported on November 4 that after updating to desktop package 26.1029.7803.0, fully shutting down the app and reopening it, browser control worked again in both Work and Codex desktop chats. Codex in VS Code still failed on the same machine, and the user couldn't tell which of the steps made the difference. Treat it as one report that matches OpenAI's order, not as a confirmed fix.

Other desktop reports describe the built-in browser tab visibly open while the agent sees an empty browser list ([#55173](https://github.com/openai/codex/issues/55173), macOS 26.1013.40934), fresh chats not helping on Windows ([#58856](https://github.com/openai/codex/issues/58856)), and `@Chrome` failing inside a desktop Codex chat on macOS ([#59756](https://github.com/openai/codex/issues/59756)). If you reach step 5, send the feedback with the chat ID and add your versions to the GitHub thread.

## @Chrome and other browsers through the ChatGPT extension: OpenAI's check order

The ChatGPT extension lets a desktop app chat work in Chrome, Edge, Brave, Opera or Vivaldi with your signed-in sessions ([OpenAI's extension guide](https://learn.chatgpt.com/docs/chrome-extension)). These checks apply when you mention the browser from a Work or Codex chat in the desktop app. If you used `@Chrome` from the terminal, `codex exec` or an IDE, you are on the CLI route and the list below won't change the result (for example [#59592](https://github.com/openai/codex/issues/59592) with `codex exec` and [#60130](https://github.com/openai/codex/issues/60130) with CLI 0.167.0).

OpenAI's order when ChatGPT can't connect to your browser:

1. Make sure the website you want ChatGPT to use isn't in the blocklist in Settings.
2. Update the ChatGPT desktop app, and update or remove any extra ChatGPT or Codex desktop apps.
3. Restart the browser. In Chrome, Edge, Brave or Vivaldi, reopen ChatGPT from the toolbar or Extensions menu and confirm the side chat loads. Opera has no side chat, so check its connection from the desktop app.
4. In **Settings > Computer Use**, confirm the browser is listed and shows **Manage**. If it still shows **Install**, run the setup again: select **Install**, add the extension from the store page, then return and check for **Manage**. Expand **More browsers** if your browser isn't in the main list.
5. If the browser is missing from the @-mention menu, turn on its toggle in Computer Use.
6. Use the browser profile where the extension is installed. With several profiles, install and enable the extension in the active one.
7. Start a new ChatGPT Work or Codex chat and try again.
8. Restart the ChatGPT desktop app. If the extension still doesn't connect, reinstall it through **Settings > Computer Use**.
9. Still failing: run `/feedback` in the app and include the chat ID when you contact support.

OpenAI also notes that browser availability "can depend on rollout and your workspace settings," so a work account can behave differently from a personal one on the same computer.

## Similar Codex browser messages that need a different fix

These come from other checks, so the steps above won't match them:

- **`Local browser use is disabled in Work settings`** is a separate desktop message. A user on Windows reported getting past it by ending the app in Task Manager and reopening it ([OpenAI Developer Community thread](https://community.openai.com/t/codex-bug-built-in-browser-access-intermittently-blocked-by-local-browser-use-is-disabled-in-work-settings/1408172)).
- **`Disabled by your organization or unavailable in your region`** in **Settings > Browser** is a workspace or availability limit, not a broken connection.
- **`Failed to start codex app-server`**, Browser Use failing with `os error 3`, or the extension side panel showing `manifest entry is missing required path nodePath` on Windows come from stale paths after an update. See [Failed to Start Codex App-Server on Windows: Fixes by Error Text](/en/posts/codex-app-server-failed-to-start).

## Reporting the browser access host error: versions to include

For a failure inside the desktop app, OpenAI's route is `/feedback` in the app plus the chat ID when you contact support.

For the CLI, IDE and host-app route, comment on [#57641](https://github.com/openai/codex/issues/57641) instead of opening a new issue. New issues keep getting flagged as duplicates of it. Include:

| Detail | Where to find it |
| --- | --- |
| ChatGPT desktop app version | About in the app, or the installed package (on macOS, `CFBundleShortVersionString` in the app's `Info.plist`; on Windows, the `OpenAI.Codex` package version) |
| Bundled browser plugin versions | Folder names under `~/.codex/plugins/cache/openai-bundled/<plugin>/`, for example `chrome` and `unified-computer-use`. On macOS and Linux, `chrome/latest` links to the current one. On Windows the plugins live under `%USERPROFILE%\.codex\plugins\`. |
| Codex CLI version | `codex --version` |
| Where you launched Codex | Terminal, `codex exec`, VS Code, JetBrains, host app name, SSH target |
| Browser and OS | For example Chrome on macOS 26.1, Brave on Windows 11 |
| Whether a desktop app chat on the same machine works | The single most useful line for separating the two failure types |

## Questions about the Codex browser access host error

### Which Codex version fixes "The browser access host is unavailable"?

None, as of November 11, 2026. No release note or OpenAI maintainer names a fixed version. CLI 0.167.0 and 0.167.1 don't mention the issue, and desktop app 26.1103.60933 still fails from CLI 0.166.0. Check the [Codex changelog](https://learn.chatgpt.com/docs/changelog) and [#57641](https://github.com/openai/codex/issues/57641) before trusting any claim of a fix.

### Can I roll back Codex CLI to get browser access back?

Rolling the CLI back to 0.164.0 didn't help in [#57641](https://github.com/openai/codex/issues/57641). Most reporters tie the break to desktop app updates in late October, and no report shows a CLI downgrade bringing browser access back.

### Is my Chrome or the ChatGPT extension broken?

Probably not if a desktop app chat on the same computer can use `@Chrome`. In that case the browser and extension are fine and only the session that started outside the desktop app is refused. If the desktop chat fails too, work through [OpenAI's extension checks](#chrome-and-other-browsers-through-the-chatgpt-extension-openai-s-check-order).

### Will Codex CLI and the IDE extension get browser access again?

Unknown. OpenAI's documentation currently says Browser isn't available in Codex CLI or the IDE extension, and no one from OpenAI has commented on the GitHub reports. Until that changes, plan on running browser steps from the ChatGPT desktop app.