›_ Codex Issues
Codex Issues / #34583

Chrome and Computer Use fail when desktop app uses a custom CODEX_CLI_PATH build

Open 💬 1 comment Opened Jul 21, 2026 by winnal

Summary

The ChatGPT/Codex desktop app accepts CODEX_CLI_PATH to run a locally built Codex CLI, but enabling that override makes both the Chrome plugin and Computer Use unavailable on macOS.

Reproduction

  1. Build Codex locally and point CODEX_CLI_PATH at the resulting binary.
  2. Launch the packaged ChatGPT desktop app (observed on release 26.707.30751).
  3. Install and enable the bundled Chrome plugin and ChatGPT Chrome extension.
  4. Start a Codex task that invokes Chrome or Computer Use.

Actual behavior

Chrome setup fails with:

Browser is not available: extension

Computer Use fails with:

SkyComputerUseTransportError: Sky Computer Use native pipe startup failed

The desktop logs repeatedly report:

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

The packaged app, Chrome native host, browser runtime, and extension can all be correctly installed and signed. A normal local Codex build is ad-hoc signed and has no Apple Team ID, so the packaged native-pipe peer authorizer rejects the custom CLI path.

Expected behavior

A developer-supported override such as CODEX_CLI_PATH should remain compatible with desktop capabilities, or the app should provide an explicit, user-controlled development trust workflow and an actionable error explaining the incompatibility.

Possible trust mechanisms include an explicit binary hash, a user-selected signing identity, or a clearly marked local-development opt-in. If custom CLI builds are intentionally unsupported with Chrome and Computer Use, that limitation should be documented next to CODEX_CLI_PATH and surfaced in the UI instead of appearing as an extension installation failure.

Impact

This prevents developers who rely on local Codex builds from using Chrome and Computer Use in the packaged desktop app, even though the custom CLI override itself continues to work for ordinary tasks.

View original on GitHub ↗

1 Comment

100yenadmin · 1 month ago

Corroborating this on a newer current build with an intentional custom CODEX_CLI_PATH runtime:

  • ChatGPT desktop: 26.721.41059 (build 5848), arm64
  • Computer Use bundle: 26.721.1000502 (1000502)
  • Custom Codex executable: checksum-gated local build, valid ad-hoc signature, TeamIdentifier=not set
  • The ChatGPT, Computer Use, SkyComputerUseClient, and Guardian bundles all pass code-signature verification

Observed result:

SkyComputerUseTransportError: Sky Computer Use native pipe startup failed

At the corresponding attempts, SkyComputerUseService records:

Sender process is not authenticated
MacOS error: -67062

A read-only relay experiment also rules out a tempting workaround: the bundled, OpenAI-signed SkyComputerUseClient mcp executable successfully handles MCP initialization and tools/list, but a read-only list_apps call still reaches the service's signature verification and fails with -67062. Running the signed client as a custom stdio MCP therefore does not bypass the process-ancestry authorization boundary.

The installed Desktop code also shows that CODEX_BROWSER_USE_PEER_AUTHORIZATION=1 only enables the authorizer in a non-packaged/dev mode; setting it to 0 cannot disable authorization in a packaged build. The native authorization module contains OpenAI Team ID 2DC432GLL2, signing-identifier allowlists, and peer/parent/grandparent checks, consistent with the ancestry findings in #30155.

This leaves no supported compatibility path for an ad-hoc custom CLI while preserving native Computer Use. An explicit user-approved trust record for an exact custom binary hash, or an OpenAI-signed broker/relay designed for CODEX_CLI_PATH, would preserve the security boundary without requiring developers to discard local fixes.