Chrome plugin connection fails with missing-code-signing-identity #30155

Activity

1. jQSfire125

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 26, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   browser

   on Jun 26, 2026
3. github-actions commented on Jun 26, 2026

   

   github-actionsbot

   on Jun 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Chrome bridge backend unavailable on macOS despite healthy Chrome extension/native host #29389
   • Chrome plugin cannot connect after reinstall/restart #29999

   Powered by Codex Action
4. yuzhang-cao commented on Jun 30, 2026

   

   yuzhang-cao

   on Jun 30, 2026 – with ChatGPT Codex Connector

   More actions

   Also reproducible on:

   • macOS 26.4.1 (25E253), Apple Silicon
   • Codex app: 26.623.70822
   • Bundled CLI: 0.142.4
   • Chrome: 149.0.7827.197
   • Codex Chrome Extension: 1.1.5, Profile 2
   • Feedback/thread ID: 019f114e-c19d-70c2-94ab-f8d9f4266761

   Observed:

   • Browser is not available: extension
   • agent.browsers.list() returns []
   • Log repeatedly reports:

     browser-use native pipe rejected socket peer
     reason=missing-code-signing-identity
     

   Verified:

   • Extension is installed and enabled.
   • Native host manifest is correct.
   • Chrome plugin was removed and reinstalled.
   • Chrome, Codex, and macOS were restarted.
   • Codex.app is accepted as Notarized Developer ID.
   • Native host code is valid and signed by OpenAI OpCo, LLC (2DC432GLL2).
5. doogie-bigmack commented on Jul 6, 2026

   

   doogie-bigmack

   on Jul 6, 2026

   More actions

   I have this same issue

   • @chrome still fails: agent.browsers.list() returns []; agent.browsers.get("extension") returns Browser is not available: extension.

     • Chrome is running.
     • Codex Chrome extension is installed/enabled in profile Default.
     • Native host manifest is correct.
     • Reinstalled chrome@openai-bundled using supported CLI commands.
     • Opened a fresh Chrome window for the selected profile and retested.
     • Fresh Codex logs still show: browser-use native pipe rejected socket peer reason=missing-code-signing-identity.

     This is a known upstream issue, not a Security Civilization repo issue and not something reinstalling the Codex CLI fixes. Matching open issues:

     • Chrome plugin connection fails with missing-code-signing-identity #30155
     • Codex Chrome bridge backend unavailable on macOS despite healthy Chrome extension/native host #29389
     • Chrome plugin cannot connect after reinstall/restart #29999
     • Chrome plugin backend unavailable despite extension showing Connected #25811

     Current local versions:

     • Codex CLI: 0.142.5, latest published npm/GitHub CLI release.
     • Codex Desktop: 26.623.101652.
     • Chrome plugin: 26.623.101652.
       Get this fixed!
6. hectorlcastro09 commented on Jul 11, 2026

   

   hectorlcastro09

   on Jul 11, 2026

   More actions

   Confirmed on macOS 15.7.7 (Intel x86_64) — ChatGPT app 26.707.41301, bundled Chrome plugin 26.707.41301, standalone codex-cli 0.144.1, Chrome 149.0.7827.201, extension 1.2.27203.26575. Every agent.browsers.get("extension") attempt from a terminal session correlates 1:1 with a browser-use native pipe rejected socket peer reason=missing-code-signing-identity warning in the desktop app log, while all of Codex's own diagnostics (extension installed/enabled, native host manifest, host process, chrome-native-hosts-v2.json presence) report healthy.

   I dug into the authorizer (ChatGPT.app/Contents/Resources/native/browser-use-peer-authorization.node). It resolves the peer via getsockopt(LOCAL_PEERTOKEN) → SecCodeCopyGuestWithAttributes → SecCodeCopySigningInformation, hardcodes TeamIdentifier 2DC432GLL2 plus a signing-identifier allowlist (codex, com.openai.codex{,.agent,.alpha,.beta,.dev,.nightly,.runtime}, node, node_repl), and — per its strings (peer, peer parent, peer grandparent, failed to read … code signing identity) — it validates the process ancestry chain, not just the peer itself.

   Decisive experiment: dialing the live pipe with OpenAI's own signed Node binary (/Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node, Identifier node, Team 2DC432GLL2) launched from bash gets rejected with the exact same reason (new log line appears immediately). The only non-OpenAI element in that chain was the shell. A terminal-launched CLI always has the user's shell (an Apple platform binary with no OpenAI TeamIdentifier) within two ancestry hops, so authorization can never pass from a terminal — which matches the symptom pattern across these reports: desktop app flows work, terminal/CLI/VS Code sessions are rejected.

   This also explains why reinstalling the plugin never helps: the rejection happens inside the app's pipe server, before any plugin code is involved.

   Suggested fix directions: stop walking the ancestry once an allowlisted OpenAI-signed process is found; or treat Apple platform binaries (shells/terminals) as neutral ancestry; or have the connection dialed by a process whose 2-hop ancestry stays within OpenAI-signed processes (e.g. the sandboxed REPL kernel).
7. dobromirivanov1 commented on Jul 13, 2026

   

   dobromirivanov1

   on Jul 13, 2026

   More actions

   Still reproducible on a newer environment:

   • ChatGPT desktop: 26.707.62119 (build 5211)
   • macOS: 26.5.2 (25F84), Apple Silicon
   • Google Chrome: 150.0.7871.114
   • ChatGPT Chrome extension: 1.2.27203.26575

   Observed:

   • agent.browsers.get("extension") reports Browser is not available: extension.
   • Each connection attempt produces browser-use native pipe rejected socket peer reason=missing-code-signing-identity in the desktop log.

   Verified locally:

   • The extension is installed and enabled in the selected Default profile.
   • The native-host manifest is valid and contains the expected extension origin.
   • Chrome launches the native-host process successfully.
   • The host is arm64, executable, signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), and has a valid signature.
   • The cached native-host binary is byte-identical to the copy bundled inside ChatGPT.app.
   • ChatGPT.app passes strict deep code-signature verification.
   • Opening a fresh Chrome window and retrying does not help.

   This confirms the issue remains present in the 26.707.62119 release and Chrome 150; it is not resolved by the newer extension/native-host build.
8. koppula commented on Jul 19, 2026

   

   koppula

   on Jul 19, 2026

   More actions

   Additional data point: the "alias the app-bundled codex binary" workaround does NOT work on build 26.707.72221 -- addon-level verdicts included

   Environment:

   • macOS Tahoe 26.5.2 (25F84), arm64
   • ChatGPT desktop app 26.707.72221
   • codex CLI: npm 0.144.4 (/opt/homebrew/bin/codex, shim under homebrew node 25.9.0, which is adhoc-signed) and app-bundled 0.144.2 (/Applications/ChatGPT.app/Contents/Resources/codex)
   • Chrome 150.0.7871.125; Codex extension installed + enabled; native host (extension-host/macos/arm64/ChatGPT for Chrome) validly signed, spawned by Chrome, and listening on its /tmp/codex-browser-use/*.sock

   Symptom matches this issue exactly: agent.browsers.get("extension") -> Browser is not available: extension, agent.browsers.list() -> [], while every plugin self-check passes. The desktop app log records a rejection at the exact minute of every attempt:

   warning [browser-use-native-pipe-server] browser-use native pipe rejected socket peer reason=missing-code-signing-identity

   Findings beyond what's already in the thread:

   1. The community workaround from Chrome backend unavailable in terminal/API session: untrusted-code-signing-identity while Codex App @Chrome works #30545 (use the app-bundled signed binary) fails on this build. A headless run of /Applications/ChatGPT.app/Contents/Resources/codex exec (0.144.2) doing only setupBrowserRuntime + agent.browsers.list() returned [], with two missing-code-signing-identity rejections logged at the matching timestamp. So on 26.707.x it is not just unsigned/npm installs that are rejected.
   2. Addon-level verdicts. I loaded ChatGPT.app/Contents/Resources/native/browser-use-peer-authorization.node in a standalone Unix-socket server and called authorizeSocketPeer(fd, flag) on accepted connections:

   • Peer = OpenAI's own cua_node/bin/node (TeamIdentifier 2DC432GLL2, identifier node), launched from zsh:
     {"authorized":false,"teamId":"2DC432GLL2","signingIdentifier":"node","reason":"missing-code-signing-identity"}
     The peer's identity was read successfully (it's in the verdict), so the "missing" identity is an ancestor's. Both values of the boolean flag give the same result.
   • Peer = homebrew node (adhoc): {"authorized":false,"reason":"missing-code-signing-identity"}
   • Peer = /usr/bin/nc (Apple platform binary): same rejection.

   3. Ancestry is the deciding factor. Failing npm session tree: node_repl (2DC432GLL2) <- vendor codex (2DC432GLL2) <- homebrew node (adhoc) <- zsh. Failing app-bundled tree: node_repl <- codex (2DC432GLL2) <- zsh (Apple platform, no TeamIdentifier). csops(CS_OPS_STATUS) shows every involved process is CS_VALID and signed at runtime, so this is a policy rejection, not binary corruption. Any terminal launch puts a shell (or an adhoc node) inside the checked window, so terminal sessions can never authorize on this build.
   4. Desktop-app UI @chrome threads work on the same machine (tree node_repl <- codex <- ChatGPT.app, all 2DC432GLL2): those days show zero rejections in the log and Chrome is driven normally. Logs on this machine go back through the older Codex.app (failed to read peer parent code signing identity variant from early July): zero terminal authorizations have ever succeeded.

   Suggested direction: terminate the ancestry walk at the first allowlisted OpenAI-signed ancestor (the codex/node_repl chain itself proves provenance), or accept Apple platform binaries (shells, login) as neutral links. As-is, the check structurally excludes every terminal-launched CLI session regardless of how codex was installed.

   Also confirming for other readers: reinstalling the app/plugin/extension does nothing (the rejection happens before any of them are consulted), and a failed discovery is cached for the life of a codex process, so always retest in a fresh session.