In-app browser commands stopped working

[icarogamatos]

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.

5. Try another browser action, for example:

   Click the Images tab.

6. Try a direct navigation action, for example:

   Open https://openai.com.

7. 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

[github-actions]

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

• [Windows] Browser plugin fails with "browser-client is not trusted" despite advertised chrome and iab backends #21781
• Windows: browser-use@openai-bundled times out and never starts the in-app browser (iab), while @chrome can connect #21912
• Codex Desktop bundled Browser/Chrome plugins not available or failing on Windows #22598

Powered by Codex Action

[icarogamatos]

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]

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]

@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]

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.

[mickitty0511]

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

#21781 (comment)