Repository navigation
Browser skill is mounted in CLI TUI even when no in-app browser backend is available #25647
Description
What issue are you seeing?
When using the Codex CLI TUI directly, the bundled Browser / in-app browser skill is still mounted and advertised even though there is no Codex desktop app in-app browser backend available for the session.
This makes @Browser / $browser look usable in the CLI TUI, but the Browser runtime cannot discover any browser backend:
agent.browsers.list() => []
agent.browsers.get("iab") => Browser is not available: iab
The confusing part is that the skill itself is present and its browser-client.mjs can be loaded, so the agent spends time trying the Browser bootstrap path before discovering that no iab backend exists. In a pure CLI TUI session, there is no in-app browser pane for the skill to attach to.
Environment
- Codex CLI:
codex-cli 0.135.0 - Platform: macOS 26.5 / Darwin 25.5.0 arm64
- Session type: CLI TUI launched directly from a terminal, not the Codex desktop app
- Browser plugin cache exists locally under
~/.codex/plugins/cache/openai-bundled/browser/...
Steps to reproduce
- Launch
codexas the CLI TUI directly from a terminal. - Ask Codex to use
$browser/@Browserfor a quick in-app browser check. - Observe that the Browser skill is mounted and the agent attempts to use the Browser plugin.
- The runtime reports no available browser backend, e.g.
agent.browsers.list()returns[]andagent.browsers.get("iab")fails.
Expected behavior
For CLI TUI sessions that are not attached to a Codex desktop app in-app browser backend, either:
- do not mount/advertise the in-app Browser skill at all, or
- expose it as unavailable with a clear immediate message such as:
The in-app browser requires the Codex desktop app and is unavailable in CLI TUI sessions.
Actual behavior
The Browser skill is mounted and looks available, but no usable browser backend exists. This makes the failure look like a broken Browser plugin, missing extension, or IAB discovery regression, when the real issue is that the CLI TUI has no in-app browser surface.
Why this matters
It causes avoidable confusion between three separate cases:
- Codex desktop app in-app browser (
iabbackend) - Codex Chrome extension / real browser control
- CLI TUI with no browser backend
For users who explicitly do not want the Chrome extension and only want the in-app browser, the current CLI TUI behavior suggests that in-app browser support should work when it cannot.
Activity
github-actions commentedon Jun 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
JoeRoddy commentedon Jun 1, 2026
A totally different app, but likely the same issue? I would suspect this issue may exist in any exposed surface that codex offers where skills are supported, other than the codex desktop app.
daronspence commentedon Jul 29, 2026
Fresh reproduction on Codex CLI 0.145.0 on macOS. This issue still occurs in a standalone interactive CLI session.
Environment state:
browser@openai-bundledis installed and enabled.browser_useandin_app_browserare enabled.When asked to open a local development URL and capture a screenshot, Codex attempted the Browser workflow and eventually reported:
That remediation is misleading in the standalone CLI: there is no in-app browser surface to enable or open for that CLI session. The plugin/skill being advertised caused the agent to offer and attempt an impossible action.
Please capability-gate Browser exposure when constructing a CLI session. If there is no registered browser backend and no external browser MCP, the CLI should either:
Ideally, the CLI should only offer browser-backed screenshots/navigation after confirming that a usable backend exists. This avoids wasted tool attempts and prevents users from being sent through setup steps that cannot make an app-scoped browser available to a standalone CLI session.
PaulRBerg commentedon Aug 13, 2026
This still occurs for me in a standalone Codex CLI session.
The only practical workaround is to manually edit
~/.codex/config.tomlwhen using Codex CLI, then manually enable the in-app browser again when using the ChatGPT desktop app. Since both surfaces share that configuration, I cannot use the CLI and the desktop app with the in-app browser at the same time.I proposed separating the CLI configuration from the desktop app configuration in #38193.