›_ Codex Issues
Codex Issues / #30545

Chrome backend unavailable in terminal/API session: untrusted-code-signing-identity while Codex App @Chrome works

Open 💬 3 comments Opened Jun 29, 2026 by wwwweeia
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Chrome integration works from Codex App, but the terminal/API Codex session cannot discover or use the Chrome backend.

The Chrome extension itself appears healthy:

  • Chrome extension popup shows Connected
  • Chrome extension version: 1.1.5
  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome extension details show it is enabled
  • Site access is set to all websites
  • Service Worker console is empty
  • Codex App settings show Computer Use > Google Chrome connected

However, a terminal/API Codex session cannot access the Chrome backend and reports:

Browser is not available: extension

agent.browsers.list() returns:

[]

Environment

  • macOS arm64
  • Codex app/plugin version: 26.623.61825
  • Chrome extension: Codex v1.1.5
  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome profile: Default
  • Native host manifest check: passed
  • Extension installed/enabled check: passed

What works

In Codex App, @Chrome can open a local page using the real Chrome profile and logged-in state.

The Chrome extension popup shows Connected, and Codex App settings show Google Chrome as connected.

What fails

In a terminal/API Codex session, attempting to use the Chrome backend fails:

Browser is not available: extension

The browser list is empty:

[]

Relevant logs

Codex App logs include:

browser-use native pipe peer authorization failed
failed to read peer code signing identity
browser-use native pipe rejected socket peer reason=untrusted-code-signing-identity

Earlier behavior was similar to missing-code-signing-identity, but the current observed reason is untrusted-code-signing-identity.

Steps already tried

  1. Confirmed Chrome is running.
  2. Confirmed Codex Chrome extension is installed and enabled.
  3. Confirmed native host manifest exists and matches expected origin:

chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

  1. Restarted Chrome and Codex App.
  2. Reinstalled the Chrome plugin from Codex Plugins.
  3. Reinstalled/refreshed the Chrome extension.
  4. Started a new Codex session.
  5. Reset/reloaded the browser runtime using the latest plugin path.
  6. Checked the Chrome extension Service Worker console; no obvious extension-side error.

Expected behavior

Either:

  • terminal/API Codex sessions should be able to use the same connected Chrome backend as Codex App, or
  • the product should clearly document that Chrome backend access is only supported from Codex App threads and not from terminal/API sessions.

Actual behavior

Codex App @Chrome works, but the terminal/API session cannot access Chrome and fails with a local pipe code-signing authorization error.

Feedback ID

Submitted through Codex App feedback:

019f1286-40fc-7b92-ba40-24ef4a5778e8

Possibly related issues

  • #30155
  • #21719

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #30535
  • #30155
  • #29999
  • #29389

Powered by Codex Action

WestJohnson · 1 month ago

Confirming the same app-versus-terminal failure on newer builds, with an additional controlled comparison that may help isolate the compatibility boundary.

On the same Mac, Chrome Default profile, connected extension, native host, and plugin:

  • Standalone npm Codex 0.144.1 consistently returned Browser is not available: extension.
  • /Applications/ChatGPT.app/Contents/Resources/codex (0.144.0-alpha.4) connected successfully, opened https://example.com/, and verified the Example Domain title.

Switching only the Codex executable changed the result. Reinstalling/restarting Chrome and Codex, opening a fresh window, isolating stale sockets, and delayed retries did not fix the npm path. The current working workaround is:

alias codex='/Applications/ChatGPT.app/Contents/Resources/codex'

Environment: macOS 26.4.1 (25E253) on Apple Silicon; ChatGPT app 26.707.31428 build 5059; Chrome 150.0.7871.115; extension 1.2.27203.26575; Chrome plugin 26.707.31428.

Diagnostic references:

  • Feedback upload: 019f49d2-fc83-70a3-8377-f2c186ea2827
  • Failing Chrome task: 019f4846-068d-7402-aa5f-154f9cc3c571
  • Working comparison task: 019f49ba-79cc-7930-8480-3f20c1973d92

Originally reported with the full reproduction in #31980; consolidating here as the earlier matching issue.

dolepee · 1 month ago

Confirming this on newer builds, with an additional process-lifetime comparison that may help isolate the failure.

Environment:

  • macOS
  • ChatGPT desktop app / Chrome plugin: 26.707.91948 (build 5440)
  • Signed app-bundled Codex CLI: 0.144.5
  • Chrome extension: 1.2.27203.26575
  • Model: gpt-5.6-sol

Observed in the affected interactive terminal process:

Browser is not available: extension
Available browser list: []

The extension was installed, enabled, and connected; the native-host manifest and signed binaries validated. Retrying twice in the same process after Chrome/native-host connectivity was healthy still returned the empty browser list.

Controlled comparison: a separate fresh process using the signed app-bundled Codex CLI 0.144.5 resumed the exact same saved task and immediately connected to the active Chrome profile, detecting 18 open tabs. The fresh test then exited normally.

This suggests that an initial extension-backend discovery failure can remain cached for the lifetime of an existing terminal process. Later retries reuse the stale empty discovery state instead of re-probing the now-available extension backend.

Expected recovery:

  • retry should refresh browser backend discovery;
  • resumed tasks should reconnect after the native host becomes available; or
  • Codex should expose a supported reconnect/reset action without requiring a new process.

Uploaded feedback/thread: 019f6687-04a7-70b0-a720-e66393ac50f9