codex - 💡(How to fix) Fix Chrome Browser Use remote navigation depends on ChatGPT auth and breaks in API-key/custom-provider mode

Summary

Chrome Browser Use appears to require a ChatGPT-authenticated site_status preflight before visiting remote URLs. When Codex Desktop is running in API-key/custom-provider mode, remote Browser Use navigation fails because the ChatGPT auth token is unavailable or invalid for that preflight, even when the Chrome extension and native host are installed correctly.

This report is intentionally sanitized. I am omitting account identifiers, token values, local usernames, custom provider hostnames, private domains, and any internal URLs.

Environment

• Codex Desktop: 0.129.0-alpha.15
• macOS: 15.7.4
• Browser backend: Google Chrome via Codex Chrome Extension
• Chrome: 147.0.7727.138
• Codex Chrome Extension: installed and enabled, version 1.1.4_0
• Chrome plugin bundle observed locally: openai-bundled/chrome 0.1.7
• Model provider setup: OpenAI-compatible custom provider using the Responses API
• Model auth mode after restart: ApiKey, observed in Codex logs as auth_mode="ApiKey"

What I expected

A user should be able to:

1. Use API-key/custom-provider mode for model requests and billing/quota.
2. Use the Chrome Browser Use extension for remote pages.
3. Keep a separate ChatGPT login available for Browser Use safety/policy preflight if that preflight requires ChatGPT auth.

If this mixed mode is not supported, Codex should show a clear product-level error or documentation note saying that remote Chrome Browser Use requires ChatGPT login mode and is incompatible with API-key mode.

Actual behavior

The behavior seems to depend on the selected Codex auth mode:

• With ChatGPT login only, https://chatgpt.com/backend-api/me succeeds, https://chatgpt.com/backend-api/aura/site_status?... succeeds, and Chrome Browser Use can navigate to https://www.google.com/.
• With API-key/custom-provider mode, the same site_status chain fails before the target site loads. Earlier repros returned 401 Unauthorized with the body text Could not parse your authentication token. Please try signing in again. or surfaced as Codex auth token is unavailable / Browser Use cannot determine if ... is allowed.
• In a hybrid local test where ChatGPT tokens and an API key were both present in the local auth file, after restarting Codex Desktop the app selected auth_mode="ApiKey". Model requests used the API-key path, but Browser Use still did not have a working ChatGPT-authenticated preflight path.

Reproduction outline

1. Install and enable the Codex Chrome Extension.
2. Confirm Google Chrome is running.
3. Confirm the native messaging host manifest exists and allows the Codex Chrome Extension origin.
4. Configure Codex Desktop to use an OpenAI-compatible custom provider with an API key.
5. Restart Codex Desktop.
6. Confirm logs report auth_mode="ApiKey" for model requests.
7. Try to use Chrome Browser Use to navigate to a remote HTTPS URL such as https://www.google.com/.
8. Observe that navigation is blocked before the target page loads because the Browser Use allowance/preflight cannot authenticate to the ChatGPT site_status endpoint.

Diagnostics already checked

The following were verified locally and are not the failure point:

• Chrome is installed and running.
• The Codex Chrome Extension is installed and enabled.
• The Chrome Native Messaging Host manifest exists.
• The manifest host name matches the expected host.
• The manifest allows the expected Chrome extension origin.
• The target origin was explicitly allowed in Browser Use local config.
• No target-site-specific failure was observed; the failure occurs before the remote site loads.

One extra note: manually invoking the browser client from an untrusted shell/Node context fails with privileged native pipe bridge is not available; browser-client is not trusted. I do not treat that as the main product bug, but it made it harder to reproduce the full Chrome Browser Use flow outside the trusted Codex app/plugin runtime.

Why this matters

API-key/custom-provider mode is useful for model billing and quota management, while Browser Use appears to rely on ChatGPT account authentication for remote-page policy checks. Those two concerns should ideally be separable. At the moment, using API-key mode appears to make remote Chrome Browser Use unusable or ambiguous.

Suggested fix / clarification

Any of these would make the behavior much clearer:

• Support separate credentials: API key/custom provider for model requests, ChatGPT token for Browser Use site_status and related policy checks.
• If separate credentials are unsupported, document that remote Chrome Browser Use requires ChatGPT login mode and cannot be used in API-key mode.
• Improve the error message so it says which credential is missing and which endpoint/preflight failed.
• If local Browser Use config explicitly allows an origin, clarify whether site_status is still required and why.