Chrome plugin setup can hang when unrelated browser-use sockets exist

What version of the Codex App are you using?

Codex desktop app with the bundled Chrome plugin enabled. Chrome plugin version observed locally: 1.1.4.

What platform is your computer?

macOS on Apple Silicon.

What issue are you seeing?

The Chrome plugin can time out during setup even when Chrome, the Codex Chrome Extension, and the native messaging host are all installed and healthy.

In the failing state:

• check-extension-installed.js --json reports the Codex Chrome Extension is installed, registered, and enabled.
• check-native-host-manifest.js --json reports the native host manifest is correct.
• the extension-host process is running and listening on its Unix socket.
• the native host sample shows it idle/waiting, not crashed or CPU-spinning.
• browser.user.openTabs() from the Chrome backend times out during setup/discovery.

The root cause appears to be browser backend discovery scanning every socket in /tmp/codex-browser-use/*.sock. When unrelated/non-Chrome Codex browser-use sockets are present, Chrome setup can hang before selecting the actual Chrome extension backend.

Steps to reproduce

1. Start Codex desktop app on macOS.
2. Use browser-related plugins/tools from more than one Codex chat/session so multiple sockets appear under /tmp/codex-browser-use.
3. In a session, try to use @Chrome and call browser.user.openTabs().
4. The call can time out even though the Chrome extension and native host checks pass.

Observed local evidence

/tmp/codex-browser-use contained multiple live sockets. One was owned by the Chrome extension-host; others were owned by the Codex app process. The Chrome setup call timed out while those additional sockets were present.

After removing only the non-Chrome socket pathnames from /tmp/codex-browser-use and leaving the extension-host socket, the exact same Chrome call succeeded immediately and returned the open tab list.

No Chrome reinstall or extension reinstall was needed.

Expected behavior

The Chrome plugin should filter/discover only the Chrome extension backend, or apply per-candidate connection/request timeouts so unrelated browser-use sockets cannot block Chrome setup.

Actual behavior

Chrome setup can hang/timing out during browser discovery when unrelated live browser-use sockets are present.

Workaround

Remove non-Chrome socket pathnames from /tmp/codex-browser-use, keeping the socket owned by extension-host, then retry @Chrome.

Additional notes

This may also explain cases where users report that the Chrome extension is installed/enabled and the native host manifest is correct, but openTabs() or Chrome setup still times out. The issue is not necessarily the Chrome extension install; it can be stale/unrelated socket discovery state.