Browser backends are not propagated consistently across Desktop, CLI, and collaboration subagents

What version of the Codex App are you using?

Codex Desktop / bundled Browser plugin: 26.707.51957
Codex CLI: 0.144.1

What subscription do you have?

Not included in this diagnostic.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Browser backend availability is inconsistent across Codex Desktop, Codex CLI, and collaboration subagents.

In the same fresh Desktop session, the root agent can acquire and use the Codex in-app Browser, but a spawned collaboration subagent cannot acquire the same backend. In a standalone interactive CLI session, neither the root agent nor a spawned subagent receives any Browser backend. The Chrome skill is also mounted in the CLI, but the Chrome extension backend is absent.

Observed matrix:

| Surface | Context | Result |
| --- | --- | --- |
| Desktop | root agent | agent.browsers.get("iab") succeeds |
| Desktop | collaboration subagent | Browser is not available: iab |
| CLI | root agent | Browser is not available: iab; list() => [] |
| CLI | collaboration subagent | Browser is not available: iab; list() => [] |
| CLI | root agent, Chrome client | Browser is not available: extension; list() => [] |

The Desktop root-agent control was verified by navigating a newly created controlled tab to https://example.com/:

• URL: https://example.com/
• title: Example Domain
• visible exact heading: Example Domain
• only the test tab was closed afterward

The Desktop collaboration subagent loaded the same bundled Browser skill and initialized the client from the documented absolute plugin path, but await agent.browsers.get("iab") failed. This suggests the healthy Desktop IAB registration/session route is not propagated or rebound to child threads.

The standalone CLI tests were run in real interactive TUI sessions, not with ephemeral codex exec. Both the CLI root and child had the Browser skill and the JS runtime available, but no backend registered. A separate CLI root test initialized the bundled Chrome client and explicitly called get("extension"); it also returned an empty backend list.

What steps can reproduce the bug?

A. Desktop root versus collaboration subagent

1. Start a fresh Codex Desktop task with the Browser plugin available.
2. Read the bundled browser:control-in-app-browser skill and initialize its scripts/browser-client.mjs using the documented absolute path.
3. In the root agent, run:

const rootIab = await agent.browsers.get("iab");

1. Confirm the root agent succeeds. Create a controlled tab and navigate to https://example.com/.
2. Spawn a collaboration subagent.
3. In the child, initialize the same bundled client and run exactly:

await agent.browsers.get("iab");

1. Read bootstrap-troubleshooting, then run await agent.browsers.list() once.

Actual child result:

Browser is not available: iab

The child does not receive the working parent IAB backend.

B. Standalone CLI root

1. Launch the current CLI as an interactive TUI:

codex -a never -s read-only --no-alt-screen

1. In the CLI root agent, load the bundled Browser skill/client.
2. Run exactly:

await agent.browsers.get("iab")

1. Follow documented bootstrap troubleshooting and list once.

Actual:

Browser is not available: iab
agent.browsers.list() => []

C. Standalone CLI Chrome backend

1. In a new interactive CLI root session, load chrome:control-chrome.
2. Initialize the Chrome plugin's bundled scripts/browser-client.mjs.
3. Run exactly:

await agent.browsers.get("extension")

1. Read both documented troubleshooting topics and list once.

Actual:

Browser is not available: extension
agent.browsers.list() => []

No fallback browser was used, and no files or configuration were modified.

What is the expected behavior?

• A Desktop collaboration subagent assigned browser acceptance work should either inherit/attach to the parent task's healthy IAB backend, or receive a dedicated authorized IAB backend.
• If standalone CLI intentionally cannot attach to Desktop IAB, the IAB skill should not be mounted as usable; it should fail immediately with an explicit surface-availability message.
• If Chrome control is supported from CLI, a connected Chrome extension backend should register for the CLI root and its subagents. If it is not supported, the Chrome skill should not be advertised as usable there.
• Root and child availability should be deterministic and documented.

Additional information

Related reports:

• #20678 covers IAB/Node runtime connection and session ownership failures. A comment there describes a similar subagent session-binding mismatch.
• #25647 covers the Browser skill being mounted in CLI when no IAB backend exists.
• #26470 covers empty browser backend registration more generally.

This report adds a controlled four-context comparison on the same machine and current builds, plus a separate explicit Chrome-client test. It distinguishes the Desktop child-route failure from the standalone CLI's complete absence of registered backends.