Chrome browser control fails with "unsupported Codex auth method: apikey" while custom provider works normally

What version of the Codex App are you using (From “About Codex” dialog)?

26.909.11814

What subscription do you have?

api key & ChatGPT Plus

What platform is your computer?

macOS

What issue are you seeing?

Codex Chrome browser control fails when Codex is using API-key authentication with a custom model provider.

Normal Codex model requests through the custom provider work correctly. However, Chrome browser-control APIs fail with:

unsupported Codex auth method: apikey

The affected calls include:

cua.createBrowserTab("chrome", , ...)
browser.nameSession()
browser.user.openTabs()

This appears to be specific to the Codex Chrome Extension / browser-control channel. It is not an error from the target website or its API.

As a comparison, the native macOS accessibility path:

cua.getApp("com.google.Chrome")

works correctly and can access Chrome window/page accessibility information.

Normal Codex execution using the same custom provider and API-key authentication also works correctly.

Therefore, the issue appears to be specific to the authentication handling of the Chrome browser-control channel when auth_mode is "apikey".

What steps can reproduce the bug?

1. Configure Codex to use a custom OpenAI-compatible model provider with API-key authentication.

Relevant configuration:

model_provider = "custom"

[model_providers.custom]
wire_api = "responses"
requires_openai_auth = true

2. Confirm that auth.json reports:

auth_mode = "apikey"

3. Confirm that normal Codex model execution works through the custom provider. For example:

codex exec --skip-git-repo-check "Reply OK"

This successfully returns "OK".

4. Invoke Chrome browser control using:

cua.createBrowserTab("chrome", , ...)

Alternatively, call:

browser.nameSession()

or:

browser.user.openTabs()

5. The Chrome browser-control calls fail with:

unsupported Codex auth method: apikey

6. As a control test, use:

cua.getApp("com.google.Chrome")

This works correctly through the native macOS accessibility/Computer Use path.

Expected behavior:
Chrome browser control should support API-key-authenticated Codex sessions, including sessions using a custom provider. Alternatively, browser-control authentication should be independent of model-provider authentication so that a custom/API-key model provider can coexist with the Chrome extension backend.

Actual behavior:
The custom provider and normal Codex model execution work, but the Chrome browser-control channel rejects the session solely because the Codex auth method is "apikey".

What is the expected behavior?

No response

Additional information

No response

Reproduce the failure with the documented custom provider and API-key configuration, then compare cua.createBrowserTab("chrome"), browser.nameSession(), and browser.user.openTabs() with the working cua.getApp("com.google.Chrome") path. Trace where the Chrome browser-control calls reject auth_mode "apikey". Done means browser control works with the custom/API-key session while normal execution and native accessibility behavior remain intact.