codex - 💡(How to fix) Fix Codex Desktop Chrome plugin native host connects to different socket than Codex browser-use pipe and times out

What version of the Codex App are you using?

Codex Desktop 26.506.21252

What platform is your computer?

macOS, Apple Silicon

What issue are you seeing?

The bundled Chrome plugin cannot connect to Chrome through the Codex Chrome Extension. Any @chrome task that tries to read tabs, for example browser.user.openTabs(), hangs until the tool call times out after 60 seconds.

This is not a webpage-specific failure. It reproduces before navigation, with a minimal open-tabs check.

Environment / versions

• Codex Desktop: 26.506.21252
• Chrome plugin: chrome@openai-bundled / plugin files under chrome/0.1.7
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome Extension version: 1.1.4_0
• Google Chrome: 148.0.7778.96
• Chrome profile checked by plugin scripts: Profile 1

What I verified

The plugin's own checks pass:

• Chrome is installed and running.
• Codex Chrome Extension is installed, registered, and enabled in Profile 1.
• Native messaging host manifest exists and is correct.
• Manifest host name is com.openai.codexextension.
• Manifest allowed_origins includes chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.
• Native host process starts successfully when Chrome runs.

The issue persists after:

• Fully quitting and restarting Chrome.
• Fully quitting and restarting Codex Desktop.
• Disabling and re-enabling the Codex Chrome Extension.
• Killing the extension-host process and letting Chrome relaunch it.
• Reinstalling the Chrome plugin.

Diagnostic signal

After a full restart, Codex and Chrome are both new processes and the extension native host starts, but the sockets do not line up.

Example after full restart:

Codex process holds:
/tmp/codex-browser-use/f766e672-6e34-480f-9b54-517996008edd.sock
/tmp/codex-browser-use/8119b1af-d72f-49e9-a994-cc24ce76ce63.sock

Chrome extension-host process holds:
/tmp/codex-browser-use/29c615a1-11e1-46af-8278-6d00d36366a9.sock

Earlier retries showed the same pattern with different UUIDs: Codex listens on two browser-use sockets, while extension-host connects to a separate socket. The native host process is alive, but it never appears to connect to the active Codex browser-use pipe, and the model-side browser client waits until timeout.

Steps to reproduce

1. Install/enable the bundled Chrome plugin in Codex Desktop.
2. Ensure the Codex Chrome Extension is installed and enabled in Chrome Profile 1.
3. Start Codex Desktop and Chrome.
4. Ask Codex to use @chrome, or run a minimal connection check that calls browser.user.openTabs().
5. Observe the call hangs for 60 seconds and times out.
6. Inspect local Unix sockets with lsof -U | rg 'codex-browser-use|extension-host|codexextension'.
7. Observe that the Codex process and Chrome extension-host process are attached to different /tmp/codex-browser-use/*.sock paths.

Expected behavior

The Chrome extension native host should connect to the active Codex browser-use/native pipe, and browser.user.openTabs() should return the open Chrome tabs quickly.

Actual behavior

The native host starts, but attaches to a different socket from the Codex browser-use sockets. browser.user.openTabs() never returns and the Node REPL/browser-client tool call times out after 60 seconds.

Additional notes

Running the browser client outside the trusted Codex runtime fails immediately with:

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

Inside the trusted Codex runtime, the same setup path hangs rather than returning a diagnostic error. A clearer error when the native host is attached to the wrong/stale socket would make this much easier to diagnose.