Mobile-started remote Codex thread cannot use Chrome plugin: browser-client is not trusted

What version of the Codex App are you using?

26.513.31313 (2867)

What subscription do you have?

Unknown

What platform is your computer?

macOS 26.2 (25C56) / Darwin 25.2.0 arm64

What issue are you seeing?

A Codex thread started from ChatGPT mobile through Remote connections to my Mac host cannot use the Chrome plugin, even though Chrome, the Codex Chrome Extension, and the native messaging host all appear healthy.

Important boundary:

• A normal thread started directly in the Mac Codex App can use Chrome.
• I also remember the first mobile-started remote thread being able to use Chrome.
• The failure is in a mobile-started remote Codex thread connected to the same Mac host.

The failing thread reports:

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

This looks like the mobile-started remote thread/runtime is not receiving the trusted native pipe bridge for browser-client, rather than a basic Chrome extension installation problem.

Expected behavior

When ChatGPT mobile connects to a Mac host running Codex App, a mobile-started remote thread should be able to use the host's configured plugins/browser setup. If the Chrome plugin is healthy on the host, @chrome should be able to call lightweight browser APIs such as browser.user.openTabs() or claimTab().

Actual behavior

In the mobile-started remote thread, @chrome cannot initialize browser control. The browser-client fails with:

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

Verified local diagnostics

Chrome is installed and running:

Google Chrome 148.0.7778.168

Codex Chrome Extension:

extensionId: hehggadaopoacecdllhhajmbjkdcmajg
installed: true
registered: true
enabled: true
disabled: false
version: 1.1.4_0
profile: Default

Native messaging host:

manifest exists: true
expected host name: com.openai.codexextension
name matches: true
has expected origin: true
correct: true
problem: null

Native host manifest path:

/Users/jiakesen/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json

Additional control check from a normal Mac Codex App thread on the same host:

@chrome browser.user.openTabs() succeeded and returned 22 open tabs.
Chrome backend metadata included extensionId hehggadaopoacecdllhhajmbjkdcmajg.

Current Mac-normal control thread id:

019e3b41-85c1-7741-aa5f-7a39daa95f44

Steps to reproduce

1. On macOS, install and enable the Codex Chrome plugin and Codex Chrome Extension.
2. Confirm a normal Codex App thread on the Mac can use @chrome.
3. From ChatGPT mobile, connect to the same Mac Codex App host through Remote connections.
4. Start a new Codex thread from mobile on that host/project.
5. Ask the thread to use @chrome, for example to list tabs or perform a lightweight browser availability check.
6. Observe that Chrome/extension/native host checks pass, but browser-client fails with:

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

Related issues checked

Similar but not exact:

• #21900: Chrome trusted bridge unavailable after macOS sleep/wake and Codex restart
• #21781: browser-client is not trusted despite browser backends
• #21672: Chrome setup can hang when unrelated browser-use sockets exist
• #21705: Chrome plugin times out during extension handshake
• #21851: Chrome plugin connection times out despite extension/native host checks passing
• #22264: Chrome extension shows Connected but Codex cannot control Chrome

This issue may be related, but the key additional boundary here is mobile-started remote Codex thread vs normal Mac Codex App thread.

Additional information

The official Remote connections documentation says remote access uses the connected host's projects, threads, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools. The OpenAI launch post also says the mobile app loads live state from the connected environment across active threads, approvals, plugins, and project context. That is why I expected the mobile-started remote thread to inherit the host Chrome plugin capability.