[macOS App] IAB is never rediscovered after a transient backend disconnect

Open 💬 0 comments Opened Aug 23, 2026 by kevinmnm

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

26.818.41509 (build 6962)

What subscription do you have?

Unknown / not relevant to browser lifecycle behavior

What platform is your computer?

Darwin 23.4.0 arm64 arm

What issue are you seeing?

After Codex Desktop has been open for a while and the in-app Browser has already worked, the current task/runtime can lose the iab backend. Every later lookup in that same runtime fails:

Browser is not available: iab

At that point, agent.browsers.list() returns an empty array. The Codex app process and browser renderer remain alive. A fresh task/runtime can immediately discover and use iab again without restarting the app.

This appears to be an in-memory rediscovery failure rather than an initial registration or renderer-startup failure.

Based on inspection of the bundled browser service, the likely cause is:

  • discovered browser backends are cached in this.browsers;
  • the backend close listener removes the closed backend from that cached array;
  • after the only backend closes, the cache becomes [];
  • getBrowsers() refreshes discovery only when the cache is null, not when it is empty or when the requested selector is missing.

The persistent runtime therefore keeps reusing the empty cache after a transient disconnect and never discovers a re-registered IAB backend.

What steps can reproduce the bug?

  1. Start a Codex Desktop task with the bundled Browser plugin available.
  2. In that task/runtime, initialize the documented browser client and acquire the in-app Browser:
const firstIab = await agent.browsers.get("iab"); // succeeds
  1. Use the in-app Browser successfully, then keep the same task/runtime alive. After repeated Browser use over time, allow a normal lifecycle cleanup or transient backend disconnect to occur. The exact close trigger is intermittent.
  2. In the same persistent runtime, request the backend again:
await agent.browsers.get("iab");
  1. Observe:
Browser is not available: iab
  1. Follow the documented troubleshooting path and call await agent.browsers.list(); it remains [].
  2. Start a fresh Codex task/runtime without restarting Codex Desktop. The fresh runtime immediately discovers and uses iab.

No session ID, prompt, URL, or task data is required to reproduce the lifecycle behavior.

What is the expected behavior?

A transient close or disconnect should not permanently remove the in-app Browser from a long-lived task/runtime.

When IAB re-registers, the existing Browser client should rediscover it automatically. At minimum, discovery should refresh when the cached backend list is empty or when the requested selector is absent. If reconnection cannot succeed, Codex should provide an actionable reconnect error rather than requiring a fresh task/runtime.

Additional information

Additional runtime detail: Codex Framework 151.0.7922.170.

Suggested fix:

  • Invalidate the discovery cache when a backend closes, or refresh when the cached list is empty/requested selector is absent.
  • Add reconnect/backoff handling for transient backend loss.
  • Add a regression test where IAB connects, the close listener fires, the backend re-registers, and the same Browser client resolves iab again.

Related but distinct reports:

  • #32664 covers backend propagation across Desktop, CLI, and collaboration subagents.
  • #35372 covers a remote thread losing its Browser route after archive/reopen.
  • This report concerns one local Desktop task/runtime where IAB initially works, disconnects later, and is never rediscovered by that same client while a fresh runtime works immediately.

Privacy: no project names, task/workflow names, local paths, URLs, prompts, session IDs, or logs are included.

View original on GitHub ↗