[macOS] Disabled Browser remains callable through unified Computer Use and advertised in tool instructions

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

26.901.41600, build 7982, read from the installed macOS app's Info.plist. The installed bundle is ChatGPT.app; this occurred in a local Codex task in the desktop app.

What subscription do you have?

Not specified.

What platform is your computer?

macOS 26.6.2, Apple silicon. uname -mprs: Darwin 25.6.0 arm64 arm.

What issue are you seeing?

Disabling Browser does not prevent the agent from opening and controlling the in-app browser through unified Computer Use. The agent-facing tool instructions also continue advertising the disabled backend.

The following settings were read from ~/.codex/config.toml after the successful browser operation:

[plugins."browser@openai-bundled"]
enabled = false

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."computer-use@openai-bundled"]
enabled = true

[plugins."unified-computer-use@openai-bundled"]
enabled = true

During an HTML-artifact task, the agent invoked mcp__cua_repl.js from unified-computer-use with this call (only the local artifact path is replaced):

var tab = await cua.createBrowserTab(
  "iab",
  "http://localhost:8484/test.html",
  { visible: true }
);

The call succeeded: an in-app browser tab opened and loaded the local HTML page. Subsequent screenshots, navigation, form filtering, and checkbox interactions also worked.

The initial Computer Use tool instructions explicitly exposed cua.createBrowserTab("iab", ...). The successful call returned additional instructions identifying the selected browser as “Codex In-app Browser” and documenting browser-control APIs. There was no indication that this backend was disabled.

What steps can reproduce the bug?

Observed sequence in the affected session:

1. Have Browser disabled, with Chrome and unified Computer Use enabled as above.
2. Run a local task that produces an HTML artifact and uses Computer Use for verification.
3. Invoke cua.createBrowserTab("iab", localUrl, { visible: true }) through mcp__cua_repl.js.
4. Observe that the in-app browser opens and remains controllable.
5. Read the configuration: browser@openai-bundled is still enabled = false.

This was observed in one live session; a separate clean-session/restart reproduction has not been performed.

What is the expected behavior?

The Browser setting should apply consistently across tool entry points, including unified Computer Use:

• Instructions and discovery: when Browser is off, generated Computer Use instructions and capability listings should reflect that the in-app browser is unavailable. They should direct the agent to enabled alternatives where appropriate.
• Runtime enforcement: cua.createBrowserTab("iab", ...) must be unavailable or rejected with a clear disabled-capability error. Equivalent browser APIs must enforce the same setting. Merely changing the instructions is insufficient.
• Independent capabilities: Chrome/external-browser control and native computer use should remain usable when enabled. Enabling unified Computer Use should not implicitly restore access to a separately disabled in-app browser.

Additional information

The agent also had custom instructions to use Helium for browser work. It acknowledged that choosing the in-app browser was its own instruction-following mistake. That is separate from this report: the disabled capability should still have been blocked, even after an incorrect agent choice.

The configuration additionally contains this under [mcp_servers.node_repl.env]:

BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"

This may be useful diagnostic context, but I have not established whether that separately configured Node runtime determines the backend availability of mcp__cua_repl. No root cause is claimed.

Related: #26115 and #33762 describe Browser being re-enabled on startup. This report concerns successful access through another tool while the inspected Browser setting remains false.

Start by tracing unified Computer Use instruction generation and the mcp__cua_repl.js entry point for cua.createBrowserTab("iab", ...), then compare backend checks with the Browser setting. Reproduce the behavior in a clean session if possible. Done means disabled in-app browser access is rejected and omitted from instructions while enabled alternatives remain usable.