Browser runtime permanently caches empty provider discovery #41168

What issue are you seeing?

In a Codex CLI-hosted session, the bundled Browser runtime can return
No browser is available even though the Chrome integration is healthy. The
first discovery returns an empty provider list, and that empty list is cached
for the lifetime of the JavaScript/browser runtime. A Chrome provider that
finishes registering afterward is never rediscovered.

Observed API results:

await agent.browsers.getForUrl("https://example.com/")
Error: No browser is available

await agent.browsers.list()
[]

All bundled read-only diagnostics pass:

• Chrome running: exit 0
• supported browser installation detected: exit 0
• ChatGPT/Codex Chrome extension installed and enabled: exit 0
• native-host manifest present, correct host name, and expected origins: exit 0

The local MCP environment contained
NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS="1000". Increasing that value is a
local cold-start mitigation, but it does not fix the unrecoverable empty-cache
state once discovery has already occurred.

What steps can reproduce the bug?

Environment:

• Codex CLI 0.150.1
• bundled Browser/Chrome plugin build 26.818.61809
• macOS 26.5.2 (25F84), arm64
• Google Chrome 151.0.7922.174
• Chrome extension 1.2.27268.51612_0

1. Start a Codex CLI session with Browser and Chrome plugins enabled and with a
   short native-pipe connect timeout.
2. Initialize the bundled browser runtime once using setupBrowserRuntime().
3. Call agent.browsers.getForUrl("https://example.com/") before the extension
   provider completes registration.
4. Observe No browser is available.
5. Follow bootstrap troubleshooting and call agent.browsers.list() after the
   native host/extension is available.
6. Observe that it still returns [] for the rest of the runtime.

The bundled implementation stores browsers=[] after the first refresh, while
getBrowsers() refreshes only when browsers == null. A refresh() method
exists internally but is not exposed through the public browser-client proxy.

What is the expected behavior?

• Do not cache an empty provider discovery permanently.
• Retry empty discovery with bounded backoff, or expose a documented public
  refresh() operation that the Browser troubleshooting workflow may call.
• Return typed bootstrap diagnostics that distinguish an unavailable in-app
  provider, an extension/native-pipe handshake timeout, and an actual extension
  or native-host installation defect.
• A late provider registration or transient provider disconnect should be
  recoverable without restarting the entire Codex session.

Additional information

The supported installation diagnostics passing is important: recommending a
plugin reinstall for this state is both unnecessary and ineffective. No
AppleScript, external browser automation, raw CDP, cookie access, or native-host
repair was used.