›_ Codex Issues
Codex Issues / #28199

Codex Mobile/Remote: Mini thread cannot see Mac Codex in-app browser surface

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

Component

Codex Mobile / remote connections / Codex app in-app browser / thread surfaces

Summary

A Mini/mobile remote Codex thread can control the Mac host in some ways, but it does not reliably see or use the same in-app browser/browser surface that is available from the Mac Codex app side. This breaks the expected mental model that mobile/remote is a control plane for the same host and working context.

Environment

  • Host: macOS Mac running Codex app
  • Remote client/workflow: Mini/mobile remote thread / MacBook Air remote workflow
  • Local Codex CLI version: codex-cli 0.140.0-alpha.2
  • Bundled Codex app CLI version: codex-cli 0.140.0-alpha.2
  • Date observed: 2026-06-14

Expected behavior

When a Mini/mobile remote thread is connected to the same Mac host, it should have a clear and consistent relationship to the host's browser surfaces:

  • Either it can see/use the same Codex in-app browser/browser capability available on the Mac Codex app side, or
  • The UI clearly explains that this browser surface is local-only and unavailable from mobile/remote threads.

The important product expectation is: same host should feel like the same working context.

Actual behavior

The Mini/mobile remote thread can steer the host in some ways, but it does not reliably see the same browser/thread surfaces as the Mac Codex app. In practice, the Mac/Codex app side has a browser surface available, while the Mini/mobile remote thread behaves as if that browser context is absent or not bridged.

This is especially painful because the browser is often the most important surface when steering work remotely or from mobile.

Why this matters

For non-trivial mobile/remote workflows, Codex Mobile is not just a coding chat UI. It becomes a control plane for work running on a real host. If thread state, browser surfaces, and remote control do not line up, the user has to reason about multiple partial contexts instead of one host-backed workspace.

In my workflow as a construction site manager, Codex Mobile/remote is useful far beyond coding: coordination, analysis, documentation, and steering work while moving between sites. Browser continuity is a key part of that workflow.

Related issues

This appears related to, but not exactly the same as:

  • #23302: mobile-started remote thread cannot use Chrome plugin due to browser-client trust
  • #22844: remote SSH thread can open in-app browser sidebar, but @browser is unavailable
  • #28194: projectless thread creation reliability via MacBook Air remote connection

The distinguishing point here is the broader mobile/remote/Mac continuity problem: a Mini/mobile remote thread presents as controlling the same host, but does not share the same browser/thread surface mental model as the Mac Codex app.

Reproduction status

This is based on an observed workflow issue. I can provide a tighter step-by-step reproduction or additional diagnostics if useful.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27859

Powered by Codex Action

davidmaxschmidt · 2 months ago

I ran a focused reproduction from a Mini/mobile/remote Codex session connected to the same Mac host, and I can confirm this looks like a browser/thread surface continuity issue rather than a complete lack of browser tooling.

Steps reproduced:

  • Opened a remote/mobile delegated Codex thread on the same Mac workspace.
  • Checked browser-related tool availability.
  • Loaded the Browser plugin / Codex in-app browser runtime.
  • Queried available browsers, browser capabilities, tab list, user-open tab list, and selected tab.
  • Checked the local CDP endpoint.
  • Created one temporary in-app browser tab, navigated it to https://example.com/, inspected title/URL/DOM, then closed it.

Expected behavior:
A Mini/mobile/remote Codex session connected to the same Mac host should either see/use the same Codex in-app browser/browser surface as the Mac Codex app side, or the UI should clearly explain that this browser surface is local-only and unavailable from remote/mobile threads.

Actual behavior:

  • The Browser plugin is available in the remote/mobile session.
  • The session can create, navigate, inspect, and close its own in-app browser tab.
  • It does not appear to see the existing/current Mac-side in-app browser state.
  • browser.tabs.list() returned [].
  • browser.user.openTabs() returned [].
  • browser.tabs.selected() failed with Error: No active tab found.
  • CDP inspection was also unavailable: both browser_recon_status and browser_recon_pages returned TypeError: fetch failed.

Diagnostics:

  • Codex app bundle visible on the host: com.openai.codex.
  • Codex app version: 26.609.41114.
  • Available browser reported by the runtime: Codex In-app Browser, type iab.
  • Browser metadata included codexIabTabMode: "singleTab".
  • Temporary tab control worked from the remote session: opened https://example.com/, read title Example Domain, confirmed DOM content, and closed the tab.

Conclusion:
This is specifically a browser/thread surface continuity problem across Mini/mobile/remote and the Mac Codex app. The remote thread has access to an in-app browser capability, but that capability is not continuous with the browser surface/state the user expects from the Mac Codex app side.