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:

Use API-key/custom-provider mode for model requests and billing/quota.
Use the Chrome Browser Use extension for remote pages.
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

Install and enable the Codex Chrome Extension.
Confirm Google Chrome is running.
Confirm the native messaging host manifest exists and allows the Codex Chrome Extension origin.
Configure Codex Desktop to use an OpenAI-compatible custom provider with an API key.
Restart Codex Desktop.
Confirm logs report auth_mode="ApiKey" for model requests.
Try to use Chrome Browser Use to navigate to a remote HTTPS URL such as https://www.google.com/.
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.

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

Browser Use hardcodes chatgpt.com site_status policy endpoint and breaks/leaks metadata with custom model providers #20614
Browser Use actions fail with "Codex auth token is unavailable" in API-key mode #21118

Powered by Codex Action

Adding a Windows reproduction from September 10, 2026, with more recent versions and a specific authentication-status observation.

Environment

Codex Desktop: 26.903.9818.0
Bundled Codex CLI: 0.153.4
OS: Windows
Browser: local Google Chrome through the Codex extension (extension backend)
Model provider: a custom Responses-compatible provider, with effective requires_openai_auth = false

Observed behavior and reproduction

Run Codex Desktop with the custom provider and the Codex Chrome extension installed and enabled.
Fully exit and restart Codex, with Chrome running.
Ask Codex to operate Chrome, for example to open https://dotnet.microsoft.com/en-us/download/dotnet/10.0.
The official browser runtime initializes, lists Chrome with backend type extension, and creates a browser handle successfully.
The subsequent nameSession() call fails with:

Codex auth token is unavailable

Retrying nameSession() on the same handle produces the same error. This happens before page navigation or clicking. Browser discovery succeeding therefore does not establish that browser control is working.

The same authentication error was also observed on Desktop 26.903.8094.0, with CLI 0.153.4. Browser control had worked previously, but the exact last working version and introducing change have not been isolated.

Authentication evidence

A separate status-only probe of CLI 0.153.4, using the configured custom provider, returned:

{"authMethod": null, "requiresOpenaiAuth": false}

The probe used includeToken: false and refreshToken: false; it did not request or refresh a token or send model requests.

The version-matched app-server implementation explicitly returns no authentication method or token when the active model provider has requires_openai_auth = false.

This suggests an interaction between browser authentication requirements and the active model provider's authentication status. The exact internal browser failure branch has not been proven with a complete live trace.

To distinguish this reproduction from the site_status discussion in #20614: no HTTP 403 or outbound site_status request was observed in these failed calls. This report does not attribute the failure to either of those.

Expected behavior

Using a custom provider for model requests should not leave local Chrome control failing with an unexplained missing-token error. If browser operations require a separate OpenAI sign-in, the app should clearly expose that requirement and provide a supported way to satisfy it while keeping the custom model provider.

Could this authentication interaction be investigated for the current Windows browser runtime?

Adding a Windows reproduction from September 10, 2026, with more recent versions and a specific authentication-status observation.

Environment

Codex Desktop: 26.903.9818.0

Bundled Codex CLI: 0.153.4

OS: Windows

Browser: local Google Chrome through the Codex extension (extension backend)

Model provider: a custom Responses-compatible provider, with effective requires_openai_auth = false

Observed behavior and reproduction

Run Codex Desktop with the custom provider and the Codex Chrome extension installed and enabled.

Fully exit and restart Codex, with Chrome running.

Ask Codex to operate Chrome, for example to open https://dotnet.microsoft.com/en-us/download/dotnet/10.0.

The official browser runtime initializes, lists Chrome with backend type extension, and creates a browser handle successfully.

The subsequent nameSession() call fails with:
Codex auth token is unavailable
Retrying nameSession() on the same handle produces the same error. This happens before page navigation or clicking. Browser discovery succeeding therefore does not establish that browser control is working.

The same authentication error was also observed on Desktop 26.903.8094.0, with CLI 0.153.4. Browser control had worked previously, but the exact last working version and introducing change have not been isolated.

Authentication evidence

A separate status-only probe of CLI 0.153.4, using the configured custom provider, returned:

{"authMethod": null, "requiresOpenaiAuth": false}
The probe used includeToken: false and refreshToken: false; it did not request or refresh a token or send model requests.

The version-matched app-server implementation explicitly returns no authentication method or token when the active model provider has requires_openai_auth = false.

This suggests an interaction between browser authentication requirements and the active model provider's authentication status. The exact internal browser failure branch has not been proven with a complete live trace.

To distinguish this reproduction from the site_status discussion in #20614: no HTTP 403 or outbound site_status request was observed in these failed calls. This report does not attribute the failure to either of those.

Expected behavior

Using a custom provider for model requests should not leave local Chrome control failing with an unexplained missing-token error. If browser operations require a separate OpenAI sign-in, the app should clearly expose that requirement and provide a supported way to satisfy it while keeping the custom model provider.

Could this authentication interaction be investigated for the current Windows browser runtime?

Also getting this issue......... :/

新增2026年9月10日的Windows版本，包含较新版本和特定的认证状态观察。

环境

桌面版法典：26.903.9818.0

捆绑版法典CLI：0.153.4

操作系统：Windows

浏览器：通过Codex扩展（后端）本地Google Chrome。extension

模型提供者：一个自定义的响应兼容提供者，且有效requires_openai_auth = false

观察到的行为与繁殖

运行Codex Desktop，安装并启用自定义服务商和Codex Chrome扩展。

完全退出并重启Codex，Chrome在运行中。

让Codex操作Chrome，比如打开。https://dotnet.microsoft.com/en-us/download/dotnet/10.0

官方浏览器运行时会初始化、列出带有后端类型的 Chrome，并成功创建浏览器句柄。extension

随后的呼叫失败，表示：nameSession()
Codex auth token is unavailable
在同一个手柄上重试也会产生同样的错误。这发生在页面导航或点击之前。因此，浏览器发现成功并不意味着浏览器控制有效。nameSession()

同样的认证错误也出现在桌面端，使用CLI时。浏览器控制以前是有效的，但最后一个可用的版本和引入的变更并未被孤立。26.903.8094.0``0.153.4

认证证据

使用配置的自定义提供者对CLI的单独状态探测返回：0.153.4

{"authMethod": null, "requiresOpenaiAuth": false}
探针使用的是;它没有请求、刷新令牌或发送模型请求。includeToken: false``refreshToken: false

版本匹配的应用-服务器实现在激活模型提供者拥有时，显式返回不返回任何认证方法或令牌。requires_openai_auth = false

这表明浏览器认证需求与活跃模型提供者的认证状态之间存在相互作用。目前尚未通过完整的实时追踪验证确切的内部浏览器故障分支。

为了与#20614中的讨论区分此复制：在这些失败调用中未观察到HTTP 403或外呼请求。本报告未将失败归因于上述任何一方。site_status``site_status

预期行为

使用自定义模型请求提供商不应导致本地 Chrome 控制失败，出现无法解释的缺失令牌错误。如果浏览器操作需要单独的OpenAI登录，应用应明确暴露该要求，并提供支持的方式满足该要求，同时保留自定义模型提供者。

当前Windows浏览器运行时能否调查这种认证交互？

看来大家都有这个问题

新增2026年9月10日的Windows版本，包含较新版本和特定的认证状态观察。

环境

桌面版法典：26.903.9818.0

捆绑版法典CLI：0.153.4

操作系统：Windows

浏览器：通过Codex扩展（后端）本地Google Chrome。extension

模型提供者：一个自定义的响应兼容提供者，且有效requires_openai_auth = false

观察到的行为与繁殖

运行Codex Desktop，安装并启用自定义服务商和Codex Chrome扩展。

完全退出并重启Codex，Chrome在运行中。

让Codex操作Chrome，比如打开。https://dotnet.microsoft.com/en-us/download/dotnet/10.0

官方浏览器运行时会初始化、列出带有后端类型的 Chrome，并成功创建浏览器句柄。extension

随后的呼叫失败，表示：nameSession()
Codex auth token is unavailable
在同一个手柄上重试也会产生同样的错误。这发生在页面导航或点击之前。因此，浏览器发现成功并不意味着浏览器控制有效。nameSession()
同样的认证错误也出现在桌面端，使用CLI时。浏览器控制以前是有效的，但最后一个可用的版本和引入的变更并未被孤立。 26.903.8094.00.153.4 ``

认证证据

使用配置的自定义提供者对CLI的单独状态探测返回：0.153.4
{"authMethod": null, "requiresOpenaiAuth": false}
探针使用的是;它没有请求、刷新令牌或发送模型请求。 includeToken: falserefreshToken: false 版本[匹配的应用-服务器实现](https://github.com/openai/codex/blob/rust-v0.153.4/codex-rs/app-server/src/request_processors/account_processor.rs#L1034-L1054)在激活模型提供者拥有时，显式返回不返回任何认证方法或令牌。`requires_openai_auth = false` 这表明浏览器认证需求与活跃模型提供者的认证状态之间存在相互作用。目前尚未通过完整的实时追踪验证确切的内部浏览器故障分支。为了与[#20614](https://github.com/openai/codex/issues/20614)中的讨论区分此复制：在这些失败调用中未观察到HTTP 403或外呼请求。本报告未将失败归因于上述任何一方。 site_statussite_status

预期行为

使用自定义模型请求提供商不应导致本地 Chrome 控制失败，出现无法解释的缺失令牌错误。如果浏览器操作需要单独的OpenAI登录，应用应明确暴露该要求，并提供支持的方式满足该要求，同时保留自定义模型提供者。
当前Windows浏览器运行时能否调查这种认证交互？
看来大家都有这个问题

是否有解决方法，因为这个问题困扰了我两天了，是否可以通过降级的方法恢复使用？

Adding a Linux / Azure OpenAI-only reproduction verified on September 12, 2026, matching the missing-token behavior in the September 10 Windows reproduction. This adds a no-ChatGPT-account case, post-reinstall results, and a possible earlier failure point than site_status.

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

Desktop package: 26.908.40834 (verified from the installed Linux chatgpt package, not the About dialog).
Bundled CLI: codex-cli 0.154.0-alpha.6.2.
Browser / Chrome / Unified Computer Use plugins: 26.908.40834, installed and enabled.
Chrome: 151.0.7922.173.
ChatGPT Chrome extension: 1.26.901.11451 (hehggadaopoacecdllhhajmbjkdcmajg).

What subscription do you have?

None. Model requests use Azure OpenAI via an environment-variable API key. There is no ChatGPT/OpenAI account login or subscription in this setup. The bundled CLI's login status reports Not logged in; Azure model requests work.

What platform is your computer?

Ubuntu 24.04.4 LTS. uname -mprs:

Linux 6.17.0-1022-azure x86_64 x86_64

What issue are you seeing?

The desktop's browser API discovers the Chrome extension, but listing tabs or opening a harmless test page fails with:

Codex auth token is unavailable

Reinstalling the Chrome extension created a new discoverable extension instance, but did not change the error. Resetting the task's browser helper and retrying also failed. The failure is not just an inability to discover Chrome.

What steps can reproduce the bug?

Run the desktop app with an otherwise working Azure OpenAI Responses configuration and the Azure key available in its environment. Relevant configuration excerpt below; retain your working Azure deployment, base URL, and API-version settings:

model_provider = "azure"

[model_providers.azure]
name = "Azure OpenAI"
wire_api = "responses"
env_key = "AZURE_OPENAI_API_KEY"
# requires_openai_auth is omitted (defaults to false).
# Azure endpoint/deployment details and the key are intentionally not included.

Do not sign in to a separate ChatGPT/OpenAI account. Install and enable the official Chrome extension in the running Chrome profile.
Ask the desktop agent: “Use my regular Chrome through the extension to open https://example.com/ and read its heading.”

In the desktop's initialized cua_repl browser tool, the minimal calls demonstrating the split are:

const chromeInfo = (await cua.listBrowsers())
  .find(b => b.family === "chrome" && b.type === "extension");
// Succeeds: a Chrome extension instance is present.

await cua.listTabs({ browser: chromeInfo.id });
// Fails: Codex auth token is unavailable

A separate attempt after resetting the helper also fails:

await cua.createBrowserTab("chrome", "https://example.com/", {
  sessionName: "🔎 Extension connection check"
});
// Fails: Codex auth token is unavailable

These calls were made through the desktop's provided tool, not by importing the browser runtime from an arbitrary shell process. The error occurs on tiny initial browser calls; this is not a context-window exhaustion report.

What is the expected behavior?

Regular Chrome extension control should have a supported path for an Azure-only session while preserving browser permissions and policy checks. If a separate ChatGPT sign-in is required by design, please explicitly document and surface that requirement instead of returning a generic missing-token error after successful discovery.

Additional information

Checks and controls:

Packaged Chrome-running, extension-installation, and native-host-manifest diagnostics pass; the extension is enabled in the selected profile.
Desktop restarts and extension reinstalls did not resolve the problem. A freshly reset browser helper reproduces it.
After refreshing the configured official stable APT repository, installed and candidate desktop versions are both 26.908.40834. The store listing matches the installed extension version.
dpkg --verify chatgpt reports no packaged-file discrepancies. All 1,629 checked extension files match Chrome's local computed-hash manifest (not an independent signature verification).
In the same Azure-only task, the in-app browser successfully opened/read example.com, followed the IANA link, and navigated back.
Separately, Chrome DevTools MCP with --autoConnect worked after the user explicitly enabled Chrome remote debugging and allowed the connection. Listing existing tabs and opening, reading, and closing a temporary test tab succeeded. This is an alternative connector, not a repair of the extension.

Possible failure point — static inspection, not a complete network trace:

The installed browser-service.mjs contains an extension-specific branch in sendSessionRequest that consults readRequestHeaderEnabled() before dispatching a session command. Its callback awaits caller identity before reading the codex_browser_use_agent_request_header feature gate; identity initialization uses https://chatgpt.com/backend-api/aura/identity. getInfo is exempt from that branch, and the branch is extension-specific. This is consistent with successful discovery, failed extension commands, and successful in-app control. It does not establish an HTTP site_status failure or prove that an identity request actually went out on the network.

The community browser-helper-only model_provider="openai" workaround in Vivswan/skills#101 exposes an existing ChatGPT sign-in; it does not supply one for an Azure-only user. A status-only check with an OpenAI provider override still reported Not logged in here. That workaround was not installed.

No credentials, Azure resource names, private browsing URLs, local usernames, or raw session logs are included. No browser policy or authentication code was modified. Could maintainers confirm whether Azure-only extension control is intended to work and investigate this identity-dependent initialization path? Related API-key report #43410 has a different error (unsupported Codex auth method: apikey), so I am not assuming the failures are identical.

Adding a Windows follow-up after completing a fresh round of testing on September 13, 2026.

Symptoms

Chrome could be discovered through the extension, but reading or operating tabs failed with nodeRepl.fetch request failed. Earlier attempts had also produced unauth / authorization errors.

What resolved it in my setup

I kept Codex/ChatGPT signed in and injected the following proxy environment variables for the CUA child process through the actual cua-repl.mjs launcher:

NODE_USE_ENV_PROXY=1
HTTP_PROXY=http://127.0.0.1:10808
HTTPS_PROXY=http://127.0.0.1:10808
http_proxy=http://127.0.0.1:10808
https_proxy=http://127.0.0.1:10808
NO_PROXY=localhost,127.0.0.1,::1
no_proxy=localhost,127.0.0.1,::1

10808 is my local HTTP proxy port; other users should use their own proxy's port. This lets the CUA process use the proxy for remote requests while keeping local addresses direct. I then tested in new sessions so the child process could pick up the variables.

Verification

After a complete retest in fresh sessions in both Codex App and Codex CLI, CUA and Chrome browser control worked normally, and the earlier unauth errors no longer occurred.

This is a working local workaround for my authenticated, proxy-dependent Windows setup, rather than proof that every authentication-related failure in this issue has the same cause. Keeping the Codex/ChatGPT login was part of the working configuration; this does not establish support for a setup with no ChatGPT sign-in. Editing a bundled launcher is also update-sensitive, so a supported, persistent way to configure the CUA child process's proxy environment would be preferable (related: #42454).

Adding a Windows repro where the #45060 workaround does not apply, because the custom provider uses command-based auth.

Environment

Codex Desktop 26.930.4958.0 (MSIX), bundled CLI 26.930.41038, Windows 11 x64
Model provider: custom Responses-compatible provider (model_provider = "<custom>"), authenticated via [model_providers.<custom>.auth] — a local command that decrypts and prints a static API key
Browser: Chrome and Edge (current stable), official browser extension installed and enabled on both; both are discovered with type: "extension"
ChatGPT sign-in: yes — codex login status reports Logged in using ChatGPT, auth.json contains the full ChatGPT token set, and the desktop app was fully restarted afterwards (fresh process tree)
No third-party browser automation, patches, or proxies involved in the browser path

Symptom (persists after login + full restart)

await cua.getState() discovers all backends, but the extension backends fail:

errors: [
  "Browser 4: Error: Codex auth token is unavailable",
  "Browser 3: Error: Codex auth token is unavailable"
]

Any tab operation on the Chrome/Edge extension backends fails with Codex auth token is unavailable. The in-app browser (iab) backend works normally in the same session.

Why the known workaround does not help

Adding requires_openai_auth = true (the setting that resolves this for env_key-based providers, as discussed in #45060) to a provider that uses an auth command is rejected at config load:

Error loading config.toml: model_providers.<custom>: provider auth cannot be combined with requires_openai_auth

So there is currently no supported way to opt a command-auth custom provider into the ChatGPT identity path, even when the user is signed in to ChatGPT.

Verified locally (config validation only)

auth command + requires_openai_auth = true → rejected at config load (error above)
env_key + requires_openai_auth = true → accepted

Expectation

Since the user has a valid, freshly refreshed ChatGPT login, Browser Use should be usable in custom-provider mode; or requires_openai_auth should be combinable with command-based provider auth — or another opt-in mechanism should exist.

Update from an affected user — resolved (with caveats) on the exact setup described above.

Setup: Windows 11, Codex Desktop 26.930.4958.0, custom Responses-compatible provider with command-based auth ([model_providers.<name>.auth]), Chrome + Edge extension backends, ChatGPT login active.

What made Browser Use work end-to-end:

Authentication leg ("Codex auth token is unavailable"):
- Converted the provider from command-based auth to env_key (moved the static API key to a user-level env var), then added requires_openai_auth = true.
- Note: requires_openai_auth cannot be combined with command-based provider auth (config load fails with provider auth cannot be combined with requires_openai_auth), so converting to env_key was required in our case.
- After this + a full app restart: the auth-token error disappeared.
Network leg ("nodeRepl.fetch request failed", contributed by a local network that requires a proxy for some domains):
- Observed via connection sampling: the native-side HTTP requests from node_repl went directly to polluted/unreachable IPs (SYN_SENT to unrelated prefixes) because the process had no proxy environment.
- Fix: injected HTTPS_PROXY / HTTP_PROXY (+ lowercase variants, NO_PROXY=localhost,127.0.0.1,::1) into the CUA child process by patching the @oai/cua-repl launcher (bin/cua-repl.mjs) inside the cua_node runtime — the same injection point as the workaround described earlier in this thread.
- Note: adding these variables via mcp_servers.node_repl.env in config.toml does not survive — the app rewrites that section on startup. Patching the bundled launcher is update-sensitive (a runtime update will drop the patch), as already flagged earlier in the thread.

Result: cua.getState() returns clean, and Chrome/Edge extension tabs can be listed and opened successfully.

Hope this helps anyone hitting the same combination.

Adding a macOS follow-up with a working configuration, tested on October 13, 2026.

Account and model provider

I am signed in to Codex Desktop with an OpenAI/ChatGPT account.
The desktop account menu shows my account with the Free plan, while the model provider is still displayed as "Azure OpenAI".
I did not switch the displayed model provider to OpenAI for this Browser Use test.
Browser backend: Google Chrome through the official Browser Use extension.

Previous behavior

The browser runtime could initialize and discover Chrome, but subsequent operations failed with:

Codex auth token is unavailable

The error occurred on initial browser operations, including nameSession(), before target-page navigation.

Current verification

After changing my setup and restarting Codex Desktop, I tested Chrome Browser Use again.

The following operations succeeded through the official Chrome Browser Use runtime:

Naming the browser session.
Listing open Chrome tabs.
Claiming an existing user tab and reading its title and URL.
Extracting rendered page text.
Navigating that tab to https://example.com/ and reading its title, "Example Domain".

No alternative browser automation mechanism was used for this verification.

Scope of this result

This demonstrates a working configuration with an OpenAI/ChatGPT account signed in and Azure OpenAI still displayed as the model provider.

I have not isolated the exact configuration change responsible for the recovery. I also have not captured a network trace of the ChatGPT identity or site_status checks, or independently verified the model request destination during this browser test.

Could maintainers clarify the supported configuration for keeping ChatGPT account authentication available to Browser Use while using Azure OpenAI for model requests, including whether requires_openai_auth = true is required for this mixed setup?

Adding another Windows reproduction, retested on October 16, 2026.

Environment

Codex Desktop 26.1007.2314.0
Codex CLI 0.162.0-alpha.17.2
Windows x64
Google Chrome through the official browser extension
Codex Desktop is signed in to an OpenAI/ChatGPT account
Model requests use an OpenAI-compatible custom/relay provider

Observed behavior

I fully restarted both Codex Desktop and Chrome.
Browser control still failed before the requested page could be read or operated.
Earlier attempts in the same mixed-auth setup failed with Codex auth token is unavailable.
The latest attempt stopped with: Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.
The request was only to open and read a normal HTTP page; no write action was requested.
Signing in to the desktop ChatGPT account and restarting did not make Chrome Browser Use reliable while the custom model provider remained active.

This looks like the model-provider authentication path and Browser Use identity/policy path are still coupled, or the extension/native runtime loses reliable URL attestation in this mixed configuration.

Expected behavior

Browser Use should keep and use the ChatGPT account authentication/policy context independently from the custom provider used for model requests. If that configuration is intentionally unsupported, the app should state that clearly and surface a specific actionable error instead of disabling Computer Use after browser discovery.

seems to be resolved in 26.1013.40934

Chrome Browser Use remote navigation depends on ChatGPT auth and breaks in API-key/custom-provider mode #21710

Description

Summary

Environment

What I expected

Actual behavior

Reproduction outline

Diagnostics already checked

Why this matters

Suggested fix / clarification

Activity

github-actions commented on May 8, 2026

liuxuan1-1 commented on Sep 10, 2026

Environment

Observed behavior and reproduction

Authentication evidence

Expected behavior

voarsh2 commented on Sep 10, 2026

Environment

Observed behavior and reproduction

Authentication evidence

Expected behavior

C-Y-T-258 commented on Sep 11, 2026

环境

观察到的行为与繁殖

认证证据

预期行为

Tom9527c commented on Sep 11, 2026

环境

观察到的行为与繁殖

认证证据

预期行为

ardaerturk commented on Sep 12, 2026

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

jeffery-zhang commented on Sep 13, 2026

Symptoms

What resolved it in my setup

Verification

going358 commented on Oct 6, 2026

Environment

Symptom (persists after login + full restart)

Why the known workaround does not help

Verified locally (config validation only)

Expectation

going358 commented on Oct 6, 2026

huqianghui commented on Oct 13, 2026

Account and model provider

Previous behavior

Current verification

Scope of this result

longhaichen commented on Oct 16, 2026

Environment

Observed behavior

Expected behavior

ardaerturk commented on Oct 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions