›_ Codex Issues
Codex Issues / #23222

In-app browser commands stopped working

Open 💬 8 comments Opened May 18, 2026 by icarogamatos
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.40821

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex in-app browser is open and works manually, but Codex cannot control it with browser automation commands.

Commands attempted:

  • Search potato and open the first result.
  • Click the visible Images tab on Google Search.
  • Open/navigate to https://openai.com from the in-app browser automation path.

In all cases, Codex cannot send browser actions. The failure happens before interacting with the webpage itself, so this does not appear to be specific to Google or any single site.

Observed error from the browser client setup attempt:

browser-client import: ok
ERROR_NAME=Error
ERROR_MESSAGE=privileged native pipe bridge is not available; browser-client is not trusted
ERROR_STACK=Error: privileged native pipe bridge is not available; browser-client is not trusted
    at Module.Ale (.../browser-client.mjs:2984:22254)

Relevant Codex logs also show:

browser_use_availability_resolved available=true browserPane=true platform=Windows reason=available release=26.513.40821

But shortly after that:

[computer-use-native-pipe] computer-use native pipe startup failed
errorMessage="Windows Computer Use helper paths are unavailable"
platform=win32

There are also repeated bundled executable relocation warnings:

bundled_executable_relocation_failed
errorMessage="Bundled executable relocation failed during mkdir_destination"
operation=mkdir_destination
originalError={"errno":-4058,"code":"ENOENT","syscall":"mkdir","path":"C:\\Users\\<redacted>\\AppData\\Local\\OpenAI\\Codex\\bin"}

This appears for bundled executables including:

rg.exe
codex.exe
node.exe
node_repl.exe

I reinstalled Codex multiple times, including a clean reinstall from the Microsoft Store, but the issue still happens.

What steps can reproduce the bug?

  1. Open Codex on Windows.
  2. Open the in-app browser.
  3. Navigate manually to a page such as Google Search.
  4. Ask Codex to perform a browser action, for example:

> Search potato and open the first result.

  1. Try another browser action, for example:

> Click the Images tab.

  1. Try a direct navigation action, for example:

> Open https://openai.com.

  1. Observe that Codex cannot execute the browser action.

The browser window itself remains usable manually, but Codex cannot click, type, or navigate through the in-app browser automation bridge.

Troubleshooting already attempted:

  1. Uninstalled Codex.
  2. Renamed the Codex folder in AppData.
  3. Restarted the computer.
  4. Reinstalled Codex cleanly from the Microsoft Store.
  5. Retried the in-app browser commands.

The issue persisted.

I do not have a project-code snippet because this is an in-app browser/native bridge issue rather than an application-code issue.

What is the expected behavior?

Codex should be able to control the in-app browser when requested.

For example:

  • If I ask Codex to search potato, it should type the query and submit the search.
  • If I ask Codex to click the Images tab, it should click that visible tab.
  • If I ask Codex to open https://openai.com, it should navigate the in-app browser there.

Manual browser use works, so the expected behavior is that Codex can also send automation actions to the same browser.

Additional information

Environment:

  • OS: Windows 10 Pro 25H2
  • OS build: 26200.8457
  • Codex Microsoft Store package: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
  • Codex app product version: 26.513.40821
  • Codex app file version: 2886
  • Embedded Codex binary version: 0.131.0-alpha.9
  • Codex command runner version: 0.131.0-alpha.9
  • PowerShell version: 7.6.1

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 2 months ago

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

  • #21781
  • #21912
  • #22598

Powered by Codex Action

icarogamatos · 2 months ago

Update: I found what fixed it.

Renaming/recreating my .codex folder under the user directory and reinstalling Codex did not solve the issue.

What actually fixed it was renaming this local app data folder:

%LOCALAPPDATA%\OpenAI

I renamed it to:

%LOCALAPPDATA%\OpenAI.old

Then I reopened Codex, letting it recreate the OpenAI local app data folder. After that, in-app browser automation started working again.

sleepyy-dog · 2 months ago

I am seeing a very similar failure on Windows with the Chrome plugin path, and it looks related to the active tool / trusted bridge exposure layer rather than the Chrome extension install itself.

Environment / local state observed:

Platform: Windows x64
Codex Microsoft Store package path includes: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
Chrome plugin: chrome@openai-bundled 0.1.7
Codex Chrome Extension: installed/enabled, version 1.1.4_0
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

The bundled Chrome diagnostic scripts all pass:

chrome-is-running.js --check -> Chrome running: yes
installed-browsers.js --check -> Google Chrome found
check-extension-installed.js --json -> installed=true, registered=true, enabled=true
check-native-host-manifest.js --json -> correct=true

However, the Codex runtime in the current thread does not expose the trusted browser / node_repl tool path needed by the Chrome skill. The local app tools cache under:

~/.codex/cache/codex_apps_tools/*.json

contains only entries like:

{ "schema_version": 2, "tools": [] }

and searching that cache shows no chrome, browser, node_repl, or openai-bundled tool entries. This matches the class of issue where the UI/config/plugin files are present, but the active chat runtime does not receive the Chrome/browser tool surface.

When trying to import the Chrome browser-client.mjs from a normal PowerShell node process, it fails with:

privileged native pipe bridge is not available; browser-client is not trusted

I understand that this specific error is expected from plain Node, but in this session there is no trusted node_repl / Chrome browser-control tool available to use instead, so the Chrome skill cannot get to browser.user.openTabs() at all.

Additional local signal: launching the packaged rg.exe directly from the WindowsApps package path failed with access denied, while the relocated copy under %LOCALAPPDATA%\OpenAI\Codex\bin exists. That may or may not be related, but it resembles the bundled executable / local app data state problems mentioned above.

I have not yet tried the workaround of renaming %LOCALAPPDATA%\OpenAI to %LOCALAPPDATA%\OpenAI.old, but this report supports that the failure can happen even when the Chrome extension and native host checks all look healthy. The remaining failure appears to be in Codex Desktop active tool injection / trusted bridge exposure for the current runtime.

icarogamatos · 2 months ago

@sleepyy-dog Thanks for the detailed write-up. This matches what I saw too: the diagnostics can look healthy, but the active Codex runtime still fails to expose the trusted browser / node_repl tool surface for the in-app browser.

One thing that fixed it for me was closing Codex, then renaming:

%LOCALAPPDATA%\OpenAI

to:

%LOCALAPPDATA%\OpenAI.old

then restarting Codex Desktop and letting it recreate the local app data/cache.

Could you try that exact workaround and report back here whether it fixes the trusted bridge / tool injection issue for you too? From your notes, it looks like you have not tested that yet.

That said, I agree this is a real Codex Desktop bug and should still be fixed by the team. The app should not get into a state where the current thread runtime does not receive the trusted browser tooling.

@etraut-openai sorry to tag you directly, but this seems related to the in-app browser/runtime tool injection layer. Sharing in case it helps narrow down the root cause. Really appreciate all the Codex Desktop bug fixes you’ve been pushing through.

mickitty0511 · 2 months ago

Hi, I was from #21781 and found this issue was related.
Tried the workaround to rename the target folder, but the same error is remaining.
Anybody else can try and report in here, but turned out not for my case.

P.S.: I restarted the app and this comment was posted right after trying.

<img width="452" height="370" alt="Image" src="https://github.com/user-attachments/assets/1caf5042-e479-4a94-a44e-d3503429d502" />

<img width="587" height="393" alt="Image" src="https://github.com/user-attachments/assets/7f5c6cae-0026-4fba-959b-f7cbdf2c1776" />

mickitty0511 · 2 months ago

or this comment might work for some cases, but not for mine

https://github.com/openai/codex/issues/21781#issuecomment-4431399447

Sichys · 1 month ago

I Asked the Codex desktop app to investigate this and it came up with this:

I found the likely problem: the Browser plugin cache looks intact, but the helper path it depends on is failing at Windows sandbox setup.

Key evidence:

  • Browser plugin is enabled in C:\Users\xxxxxx\.codex\config.toml.
  • browser-client.mjs exists at C:\Users\xxxxx\.codex\plugins\cache\openai-bundled\browser\26.602.40724\scripts\browser-client.mjs.
  • The Browser instructions say in-app browser control depends on the Node REPL helper.
  • That helper fails with: windows sandbox failed: spawn setup refresh.
  • C:\Users\xxxxxx\.codex\.sandbox\sandbox.2026-06-08.log repeatedly shows: The requested operation requires elevation. (os error 740).
  • The same failure appears as far back as June 1, while the last browser session file is May 27.
  • config.toml currently has:
[windows]
sandbox = "elevated"

So the probable cause is: Codex is configured to use the elevated Windows sandbox, but the Node/browser helper is being launched without elevation, so it crashes before it can connect to the in-app browser.

The cleanest fix to try is changing:

sandbox = "elevated"

to:

sandbox = "unelevated"

in C:\Users\xxxxxx\.codex\config.toml, then fully close and reopen Codex. If you specifically need elevated sandbox mode, then Codex Desktop likely needs to be launched as Administrator instead.

I would not start by deleting the Browser plugin cache. The plugin files are there; the failure is at the Windows sandbox/helper launch layer.

Sichys · 1 month ago

I then closed Codex and ran it as administrator and the issue was resolved for me. It came up with this;

Checked again. Running as Administrator alone did not fix it; the browser helper still hit os error 740 while sandbox = "elevated" was in C:\Users\xxxxxx\.codex\config.toml.

I changed that setting to:

sandbox = "unelevated"

and created this backup:

C:\Users\xxxxxx\.codex\config.toml.bak-codex-20260608235808

After that, the in-app browser control path worked. I was able to connect, create a browser tab, navigate it to about:blank, read the title/URL, list tabs, and close it. So the issue was the elevated Windows sandbox setting, not the Browser plugin cache.