[macOS][Chrome extension] Page.navigate reaches BOSS, then controlled tab reverts to about:blank; chrome.tabs.update path remains stable

Summary

The official Chrome plugin is installed, connected, and generally usable. A control navigation to https://example.com/ succeeds with readable DOM content. However, one official goto("https://www.zhipin.com/") call briefly returned a valid BOSS Zhipin page and then the same plugin-owned tab was observed as about:blank.

The BOSS page remains stable when opened through Chrome's visible UI, and it also remains stable through an isolated experimental route that avoids the debugger/CDP-backed navigation path. This is strong evidence of a route-specific problem, but it is not sufficient to assign the root cause to a particular source line or component.

This is being filed separately from #30841 because that issue was closed after a helper-process network-routing fix eliminated broad CDP/Playwright hangs. The current symptom is narrower: the official navigation reaches the target site successfully, then the same controlled tab later becomes about:blank.

Current environment

All values below were read from the current installation:

• macOS 26.5.2 (25F84), arm64
• ChatGPT/Codex Desktop 26.721.41059, bundle build 5848
• Codex CLI 0.146.0-alpha.3.1
• Bundled Chrome plugin/browser client 26.721.41059
• Google Chrome 150.0.7871.187
• ChatGPT Chrome extension 1.2.27221.15725 (Manifest V3)
• Test date: 2026-07-28

The route readiness check passed: the Browser and Chrome plugins were installed and enabled, and the Chrome extension host was running.

The current effective user configuration contains BROWSER_USE_DISABLE_AMBIENT_NETWORK=1, but no explicit HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, or NO_PROXY entries. I did not add proxy variables for this retest. The official example.com control still succeeded, while the BOSS deep route failed as described below.

This separates the current page-specific failure from the previous broad "nothing works until the helper network route is fixed" state. It does not prove that networking can never influence this path.

Expected behavior

After goto() reports success, the owned top-level tab should remain on the reported final URL until the caller explicitly navigates, closes, or finalizes it.

If the navigation cannot remain valid, goto() should return a clear failure instead of transiently returning success followed by an unexplained about:blank state.

Minimal reproduction

1. Fully quit and reopen ChatGPT/Codex Desktop.
2. Use the unmodified official browser client and Web Store Chrome extension with the normal Chrome profile.
3. Confirm that the extension is connected.
4. Create one new plugin-owned tab.
5. Call goto("https://www.zhipin.com/") exactly once.
6. Do not retry, click, sign in, submit a form, or switch browser routes.
7. After the call returns, wait outside the browser API and read the tab URL/title/document state again.

Actual result on the official route

• The single goto() call completed after 30.562 seconds.
• At completion, response metadata and the returned visible state showed a BOSS Zhipin page.
• The reported final location was the Tianjin landing page under https://www.zhipin.com/tianjin/.
• The screenshot at completion was non-empty.
• A follow-up observation 6.159 seconds later found the same tab at:
• URL: about:blank
• Title: about:blank
• Body/DOM: empty
• No retry was performed.

The 6.159-second value is the time of the follow-up observation, not proof that the transition happened at exactly that instant.

Controls

| Route | Target | Result |
|---|---|---|
| Official Chrome plugin | https://example.com/ | goto + DOM succeeded; final URL/title/body were readable |
| Official Chrome plugin | https://www.zhipin.com/ | Valid BOSS page returned after 30.562 s; the same tab was observed as about:blank 6.159 s later |
| Chrome visible UI via screen-level control | BOSS Zhipin | Tianjin page remained stable for more than 10 s; visible body and accessibility content were readable |
| Isolated experimental shallow route | BOSS Zhipin | One goto, 6.476 s; remained stable after a 10.001 s wait; final URL/title/body and independent tab metadata agreed |

The isolated diagnostic route used chrome.tabs.update for navigation and a read-only chrome.scripting.executeScript call in an isolated world for visible body text. It was tested only with a temporary profile and was not installed into the Default Chrome profile.

Observed shallow-route result:

• One navigation only: 6.476 seconds
• Stability wait: 10.001 seconds
• Final URL: https://www.zhipin.com/tianjin/?seoRefer=index
• Final title: BOSS直聘-找工作BOSS直聘直接谈！招聘求职找工作！
• Visible body length: 3,028 characters
• Body included BOSS直聘, 职位类型, 搜索, 热门职位, and 天津
• Body read completed in 19 ms
• Independent tab metadata returned the same URL and title
• The goto response metadata contained the final origin/path and did not contain a navigation_skipped marker
• No retry or route switch occurred

These controls show that Chrome, the current network path, and the BOSS page are generally reachable. They do not by themselves prove which official component is faulty.

Reinstallation and configuration history

The behavior persisted after reinstalling:

• ChatGPT/Codex Desktop
• The Web Store Chrome extension
• Google Chrome

It also persisted after a complete Desktop restart.

This makes a damaged executable or stale extension installation less likely, but it does not rule out persistent profile state, local routing configuration, a site-specific response, or an interaction with this Chrome version.

Historical correlation only, not causal proof: the problem appeared after a Desktop upgrade and around the same period that Chrome routing/default-profile reuse settings were changed. No controlled A/B test has established either change as the cause.

Log findings

Confirmed from the available local logs:

• No Chrome crash was recorded during the failure window.
• No Native Host crash or restart was recorded.
• No extension-service restart was recorded.
• The official call returned a valid BOSS result before the later blank state.
• A Statsig telemetry timeout appeared nearby, but the current evidence does not link it causally to the later about:blank.
• The existing logs do not identify which component caused the transition to about:blank.

The current logs do not expose enough protocol-level state to correlate one user-level goto() with every browser-client, Native Host, extension, debugger, target, and tab-lifecycle event.

Current classification

Confirmed

• The Chrome plugin is installed, connected, and capable of controlling an ordinary public page.
• example.com succeeds through the official route.
• BOSS Zhipin is stable through Chrome's visible UI.
• BOSS Zhipin is stable through the isolated shallow route.
• The official route transiently returned BOSS content, then the same tab was observed as about:blank.
• Reinstallation did not resolve the behavior.
• No component crash or restart was visible in the available logs.

Reasonable inference

The failure is more likely associated with the debugger/CDP-backed navigation and subsequent top-level target or tab-ownership lifecycle than with general Chrome availability, general network availability, or BOSS being completely unreachable.

This remains an inference, not a proven root cause.

Unknown

The available evidence cannot determine whether the responsible component is:

• The Codex browser client
• The Chrome extension service worker
• The Native Host
• Debugger attach/detach handling
• A top-level target replacement during redirects
• Incorrect frame/target association
• Tab ownership or lease finalization
• A timeout cleanup path
• Chrome's debugging API behavior
• A persistent local profile/configuration interaction
• A route-dependent response from the target site

It is also unknown whether the about:blank navigation was an intentional cleanup action, a target-selection error, or an external browser event.

Related reports:

• #30655 is the closest symptom match: a site-specific controlled Chrome page becomes about:blank. Its environment and takeover path differ from this macOS goto() reproduction.
• #30841 covers broad deep-control hangs and the earlier helper-process network-routing problem. It does not contain this delayed success-to-blank reproduction.
• #34882 identifies a concrete attach / executeCdp ordering race on Windows. I did not observe a Debugger is not attached error here, so I am not claiming the same root cause.
• #23641 covers tab.goto() failure with a native pipe close and kernel reset. No pipe, process, or kernel failure was observed here.
• #33713 covers the ambient Statsig delay. This report focuses on the additional transient-success-to-about:blank symptom.

Diagnostic logging requested

Please consider adding a redacted per-navigation correlation ID spanning the Codex client, Native Host, extension, and Chrome debugger lifecycle.

Useful timestamped events would include:

1. User-level command accepted
2. Security/policy preflight completed
3. Tab ownership or lease acquired
4. Debugger attach requested and completed
5. Navigation request sent and result received
6. Returned loader ID and navigation error text, if any
7. Top-level target ID/type changes
8. webNavigation commit and redirect events
9. tabs.onUpdated URL/status events
10. Page/load lifecycle completion
11. Final URL/title read-back
12. Debugger onDetach event and reason
13. Native Host disconnect/reconnect
14. Extension service-worker suspend/restart
15. Tab ownership/lease release
16. Any cleanup, replacement, or navigation to about:blank, including the initiating component and reason
17. The exact condition that makes goto() return success

The diagnostic export should redact cookies, tokens, passwords, Web Storage, page bodies, sensitive query values, local paths, profile identifiers, extension-instance identifiers, account information, and browsing history.

A one-click "export redacted Chrome navigation diagnostic" option would make this class of issue much easier to isolate without exposing private browser data.

Requested official guidance or fix

Please advise:

1. Whether goto() is expected to guarantee that the reported top-level tab remains on the returned URL after the call completes.
2. Whether a known timeout, lease-cleanup, target-replacement, or debugger-detach path can reset an owned tab to about:blank.
3. Whether there is a supported way to reset Chrome routing/profile state without inspecting or deleting login data.
4. Whether the official plugin can provide a non-debugger navigation fallback for sites where the deeper route is unstable.
5. Which supported diagnostic bundle should be collected for engineering review.

I can provide a redacted timestamped event timeline and repeat one controlled reproduction if engineering specifies the supported logging method. Raw logs are not attached because they may contain local paths or opaque identifiers.

Privacy and safety boundaries

All tests were read-only.

No cookies, passwords, Web Storage, session exports, account data, or browsing history were inspected. No login, click, form submission, upload, message, or external account action was performed. No Default-profile patch was installed.