[Bug]: Codex 0.154.0 Computer Use can bypass T3 collaborative browser

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server / Codex provider

Summary

With Codex CLI 0.154.0, Codex can choose its bundled cua_repl / unified-computer-use browser path instead of T3 Code's attached t3-code collaborative browser MCP, even when T3 has exposed preview_* tools and explicitly instructs Codex to use them.

When that bundled path has no available IAB browser, cua_repl fails with Browser is not available: iab. The model can then incorrectly report that the live browser is unavailable even though T3's own preview automation broker is healthy and the t3-code MCP is attached.

Steps to reproduce

1. Run a current T3 Code nightly with Codex CLI 0.154.0.
2. Start a Codex-backed thread with agent browser access enabled.
3. Give the agent a browser task where the T3 Code MCP exposes preview_status, preview_open, preview_navigate, and related tools.
4. Observe the tool route selected by Codex.

This has been observed with both gpt-6-astra and gpt-5.6-sol.

Expected behavior

When the t3-code MCP exposes preview_* tools, T3's collaborative browser should be the authoritative browser route for the session. Codex should call preview_status first and preview_open when needed before deciding browser automation is unavailable.

A failure from an unrelated bundled Computer Use browser should not be interpreted as failure of T3's collaborative browser.

Actual behavior

On affected turns Codex makes no T3 preview call and instead selects the bundled Computer Use path, for example:

server: cua_repl
tool: js
plugin: unified-computer-use@openai-bundled

It may then run:

await cua.getState();
await cua.createBrowserTab('iab', '<url>', { visible: false });

and receive:

Browser is not available: iab

The assistant can then conclude that "the live browser connection is unavailable" even though this error belongs to the bundled IAB/Computer Use path, not T3's preview_* tools.

Evidence / regression boundary

• T3 Code nightly: v0.0.41-nightly.20260913.1646
• Codex CLI: 0.154.0
• T3's t3-code MCP was attached successfully and MCP tools/list completed.
• T3's PreviewAutomationBroker remained connected.
• Historical sessions using Codex CLI 0.150.1 correctly selected t3-code tools such as preview_status, preview_open, preview_navigate, and preview_snapshot.
• The current T3 developer instructions already prefer preview_*, so the new overlapping browser-capable tool surface can still win tool selection despite the existing generic guidance.

Impact

Major degradation for Codex browser tasks in T3 Code. The user can be told that live browser access is unavailable when T3's browser is actually available, and the agent never attempts the product-native preview route.

Proposed T3-side mitigation

Harden the Codex developer instructions when preview_* tools are actually attached:

• explicitly identify cua_repl, unified-computer-use, and IAB as a separate browser surface;
• require preview_status / preview_open before any conclusion that the browser is unavailable;
• do not fall back to bundled Computer Use while T3 preview is available unless T3 preview itself returns an explicit unsupported/unavailable result or the user explicitly requests another browser;
• state that Browser is not available: iab is not evidence that T3 preview is unavailable;
• keep this entire steering block omitted when T3 preview tools are not attached.

This should be covered by regression tests in the Codex developer-instruction tests.

Upstream follow-up

Prompt steering is only a mitigation. It would be better if Codex app-server exposed a supported host/session control to suppress or deprioritize bundled Computer Use/browser tools when an embedding host supplies its own authoritative browser MCP. That likely warrants a corresponding OpenAI/Codex issue once the T3 reproducer is public.

Related issues

• #6355 is about a detached T3 preview tab and is a different failure mode.
• #7212 is about failed preview UI state and explicitly did not involve Computer Use.

Start in apps/server / Codex provider and locate the Codex developer-instruction generation and its regression tests. Reproduce with preview_* tools attached, then verify that the instructions distinguish T3 preview from cua_repl, require the preview route first, and are omitted when preview tools are absent.