codex - 💡(How to fix) Fix Computer Use fallback after Browser Use failure should preserve requested browser/session preference [1 participants]

What issue are you seeing?

In Codex Desktop on macOS, a long Browser Use session against the in-app browser lost its Browser Use pipe. Retrying Browser Use failed with:

Failed to connect to browser-use backend "iab". No Codex IAB backends were discovered. Discovery diagnostics: listedPipes=12, candidates=14, browsers=0, iabBrowsers=0, ... pipeListingError=none.

The user then explicitly authorized fallback to Computer Use and named Safari as the preferred live browser because the relevant LinkedIn authentication was already available there. Computer Use discovery returned Chrome as the frontmost app and Safari as also running. The workflow then appeared to pivot to Chrome without a clear rationale, rather than preserving the user-named Safari fallback or explaining why Chrome was safer/better.

There are already open issues that seem related to the underlying Browser Use IAB discovery failure, such as #19463 and #20678. This report is specifically about fallback behavior after Browser Use becomes unavailable: the selected live GUI/browser session should respect the user's explicit browser/session preference when one is provided.

What steps can reproduce the bug?

1. In Codex Desktop, start a Browser Use session using the in-app browser (iab) backend.
2. Run a long, modal-heavy authenticated web workflow.
3. Let the Browser Use pipe/backend become unavailable.
4. Retry Browser Use and observe an error like No Codex IAB backends were discovered with iabBrowsers=0.
5. Tell Codex to fall back to Computer Use if Browser Use still fails, explicitly naming Safari as the preferred browser/session because it has the required authentication.
6. Computer Use list_apps reports Chrome as frontmost and Safari as running.
7. The agent proceeds toward the frontmost Chrome session without documenting why it ignored the Safari preference.

What is the expected behavior?

When Browser Use cannot reattach and the user provides an explicit live-browser fallback preference, Codex should prefer that named browser/session for Computer Use. If it cannot use that browser, or if it chooses the frontmost browser instead, it should state the reason before proceeding, especially for authenticated or sensitive workflows.

A good fallback sequence would be:

1. Retry/reopen/reattach Browser Use as requested.
2. If iab discovery still fails, switch to Computer Use only after the allowed fallback condition is met.
3. Prefer the user-named live browser/session, such as Safari.
4. If another app is selected because it is frontmost or already has the right state, explicitly say so.

Additional information

This happened during a real authenticated job-application workflow. The underlying Browser Use failure was already clear and logged, but the UX issue was the unexplained surface drift from the requested Browser Use path to Computer Use/Chrome when the user had named Safari as the authenticated fallback surface.