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

[nkcbuilds]

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

• [Bug]: Leaving a thread detaches its browser preview and can leave automation unusable #6355 is about a detached T3 preview tab and is a different failure mode.
• [Bug]: Failed browser preview remains as a blank floating panel #7212 is about failed preview UI state and explicitly did not involve Computer Use.

[juliusmarminge]

Triage

This looks like a real Codex 0.154.0 regression, not a T3 preview outage.

T3 already attaches t3-code with preview_* when agent browser access is on, and already injects developer instructions that prefer those tools and forbid falling back to Chrome / Node REPL / Playwright / agent-browser. That list does not name the new bundled surface (cua_repl, unified-computer-use@openai-bundled, IAB). So Codex can skip T3 preview entirely, fail with Browser is not available: iab, and report that the live browser is down while PreviewAutomationBroker is healthy.

This is not a duplicate of #6355 (detached T3 tab after leaving a thread) or #7212 (blank floating preview; no Computer Use).

Where a T3 fix belongs

• apps/server/src/provider/CodexDeveloperInstructions.ts — harden the collaborative-browser block only when preview tools are attached
• apps/server/src/provider/Layers/CodexSessionRuntime.ts — already gates the block on MCP + preview capability; keep that
• apps/server/src/provider/Layers/CodexSessionRuntime.test.ts — existing “T3 browser developer instructions” tests

There is currently no T3 host control that disables Codex bundled plugins. Uninstalling unified-computer-use would also remove legitimate desktop Computer Use, so that is not the first fix.

Proposed T3 mitigation

When preview_* is attached:

• explicitly treat cua_repl / unified-computer-use / IAB as a separate browser surface
• require preview_status / preview_open before concluding the browser is unavailable
• do not treat Browser is not available: iab as evidence that T3 preview failed
• do not fall back to bundled Computer Use for browser work unless T3 preview itself returns unsupported/unavailable, or the user asks for another browser

Omit this entire block when preview tools are not attached.

Prompt steering is only a mitigation. A durable fix needs Codex app-server support to suppress or deprioritize bundled Computer Use/browser tools when an embedding host supplies its own browser MCP.

Accepting for the instruction + test change; marking upstream for the Codex host-control follow-up.