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

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.