›_ Codex Issues
Codex Issues / #25647

Browser skill is mounted in CLI TUI even when no in-app browser backend is available

Open 💬 4 comments Opened Jun 1, 2026 by JoeRoddy
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Launch codex as the CLI TUI directly from a terminal.
  2. Ask Codex to use $browser / @Browser for a quick in-app browser check.
  3. Observe that the Browser skill is mounted and the agent attempts to use the Browser plugin.
  4. The runtime reports no available browser backend, e.g. agent.browsers.list() returns [] and agent.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 (iab backend)
  • 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25353

Powered by Codex Action

JoeRoddy · 2 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * VS Code Codex browser plugin installed, but no session-owned browser route is registered #25353 _Powered by Codex Action_

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 · 29 days ago

Fresh reproduction on Codex CLI 0.145.0 on macOS. This issue still occurs in a standalone interactive CLI session.

Environment state:

  • browser@openai-bundled is installed and enabled.
  • browser_use and in_app_browser are enabled.
  • The bundled browser runtime is available to the agent.
  • No external browser MCP is configured.

When asked to open a local development URL and capture a screenshot, Codex attempted the Browser workflow and eventually reported:

In-app browser unavailable in this session. Browser list is empty, so I couldn’t open the local page or capture a screenshot. Enable/open in-app browser, then ask me to retry.

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:

  1. not mount/advertise the in-app Browser skill at all; or
  2. mark it unavailable immediately with an explicit message that the in-app browser requires a Codex Desktop task.

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 · 14 days ago

This still occurs for me in a standalone Codex CLI session.

The only practical workaround is to manually edit ~/.codex/config.toml when 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.