Windows: `browser-use@openai-bundled` times out and never starts the in-app browser (`iab`), while `@chrome` can connect

Summary

I'm seeing a Windows-specific problem with the in-app browser route.

[@浏览器](plugin://browser-use@openai-bundled) is enabled in Codex settings, but invoking it never brings up a usable in-app browser session. The call just hangs at the handshake stage and eventually times out.

On the same machine, I was able to get the Chrome route working again, so this does not look like a general plugin-permissions problem. It looks specific to the in-app browser (iab) backend.

Environment

• OS: Windows
• Codex Desktop: OpenAI.Codex_26.506.3741.0_x64
• Browser Use setting in Codex: enabled
• Chrome extension version: v1.1.4
• Chrome version: 140.0.7339.129

Reproduction

1. Open Codex Desktop on Windows.
2. Go to Settings -> Browser and enable Browser Use.
3. Confirm there are no blocked domains.
4. In a fresh thread, invoke:

[@浏览器](plugin://browser-use@openai-bundled)

or:

[@浏览器](plugin://browser-use@openai-bundled) 打开 https://example.com

Expected behavior

• Codex should register and start the in-app browser (iab) session.
• A usable in-app browser panel or sidebar should appear.
• The browser-use backend should become available to the thread.

Actual behavior

• No usable in-app browser panel appears.
• Browser-use calls stall at the initial handshake stage and time out.
• The thread metadata still reports the backend as available, but the runtime never successfully exposes a working iab browser instance.

What I verified

• Browser Use is enabled in Codex settings.
• The thread metadata reports:

"x-codex-browser-use-available-backends": ["chrome", "iab"]

• The trusted marketplace plugin path exists:

C:\Users\Xmage\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\browser-use

• The issue is not explained by blocked domains or the toggle being off.

Comparison with the Chrome route

On the same machine, the Chrome route was separately repaired and could reach a Connected state in the Chrome extension UI.

That strongly suggests:

• the desktop app is running,
• plugin installation is not globally broken,
• and the failure is specific to the iab in-app browser path.

Relevant diagnostics

Historical Codex desktop logs on this machine contain normal in-app browser lifecycle entries such as:

• IAB_LIFECYCLE registered browser sidebar
• browser-use native pipe listening

However, for the current failing thread, the in-app browser session does not appear to register successfully before the request times out.

In practice this looks like the desktop app knows that iab should exist, but does not actually bring the in-app browser session online for the thread.

Notes

• This does not appear to be a user configuration issue.
• This also does not appear to be caused by the Chrome extension path, because the Chrome path is a separate backend and can be brought online.
• The failure mode seems specific to Windows Codex Desktop and the in-app browser session bootstrap path.

Suggested investigation areas

• iab backend registration for the current thread
• in-app browser sidebar session startup on Windows
• mismatch between thread metadata advertising iab and actual runtime availability
• browser-use handshake timeout before a usable iab instance is exposed

I can provide screenshots and local log excerpts if needed.