Skip to content

Codex Desktop Remote SSH: in-app browser sidebar works but @browser is unavailable in remote thread #22844

Open
Open
Codex Desktop Remote SSH: in-app browser sidebar works but @browser is unavailable in remote thread#22844
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't working

Description

@neilsanghrajka
neilsanghrajka
opened on May 15, 2026

What version of Codex is running?

Local client:

  • Codex Desktop on macOS: TODO: fill from About Codex dialog
  • Connection type: Codex Desktop Remote SSH / Remote Connections

Remote host:

  • Provider: GCP VM
  • Access path: SSH over Tailscale
  • OS: Debian GNU/Linux 12 (bookworm)
  • Kernel: Linux home-vm 6.1.0-45-cloud-amd64 x86_64
  • Codex CLI: codex-cli 0.130.0

What issue are you seeing?

In Codex Desktop using the new Remote SSH / Remote Connections flow, the in-app browser sidebar can be opened manually and can load the target URL successfully.

However, inside the remote SSH-backed Codex thread, Browser Use / @browser is not available to the agent. I cannot tag @browser in the composer even though the browser sidebar itself works.

This appears specific to Remote SSH sessions. Local Codex Desktop threads do not show the same behavior.

Why this seems Remote SSH-specific

The visible browser webview is working in the desktop UI, so this does not look like a basic network/Tailscale reachability problem. The failure appears to be that the Remote SSH thread’s tool/plugin surface does not expose Browser Use / @browser, or the local browser sidebar state is not being bridged into the remote app-server session.

Recent related issues suggest Remote Connections can desync app-server/thread/tool state, but I did not find an exact issue for this Browser Use exposure problem.

Possibly related:

Steps to reproduce

  1. On macOS Codex Desktop, configure a Remote SSH connection to a GCP VM reachable over Tailscale.
  2. Open a remote project/thread through Codex Desktop Remote Connections.
  3. Open the in-app browser from the Codex Desktop sidebar.
  4. Navigate to the target URL in the sidebar browser.
  5. Observe that the URL opens and works.
  6. Return to the remote SSH-backed thread composer.
  7. Try to tag or invoke @browser.

Expected behavior

If the in-app browser is available in Codex Desktop while using a Remote SSH thread, Browser Use / @browser should be available to the agent, or the UI should clearly explain that Browser Use is unsupported for Remote SSH sessions.

Actual behavior

The sidebar browser opens and works, but @browser cannot be tagged/used in the remote SSH thread.

Additional information

This is not a generic “remote server cannot access the URL” problem: the desktop in-app browser can load the URL. The problem appears to be the Remote SSH session’s browser/tool exposure.

Activity

  1. etraut-openai
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    browser
    on May 15, 2026

  2. splitice commented on Jun 17, 2026

    @splitice
    splitice
    on Jun 17, 2026

    I tried this today and got "The browser-navigation control doesn’t appear to be exposed as a callable tool in this session, so I’m going to get the local app running first and verify the login URL. Then I’ll give you the exact local URL if I can’t programmatically steer the pane."

    What config did you use on your remote host? Unless I am a few steps behind I would say that the browser plugin is 100% not exposed to the remote session. and therefore not available for remote sessions.

  3. nbros commented on Jul 16, 2026

    @nbros
    nbros
    on Jul 16, 2026

    Yes when the agent tries to use the in-app browser in a remote thread, Codex returns "Browser is not available: iab".

  4. Turtle-Hwan commented on Jul 29, 2026

    @Turtle-Hwan
    Turtle-Hwan
    on Jul 29, 2026

    Adding a current reproduction from a newer macOS build. This remains reproducible after aligning and restarting the remote app-server with the CLI bundled in the current Desktop installation.

    Environment

    • Codex Desktop / ChatGPT app: 26.721.81911 (build 5973)
    • Bundled Codex CLI: codex-cli 0.146.0-alpha.3.1
    • Bundled Browser plugin: openai-bundled/browser/26.721.81911
    • Remote host: macOS 26.5, Apple Silicon / arm64
    • Connection type: Codex Desktop Remote SSH / Remote Connections
    • Thread source: normal user thread, not a collaboration subagent

    Current result

    The Browser skill is present and its runtime initializes, but discovery exposes only the Chrome extension backend:

    agent.browsers.list() -> [Chrome, type: extension]
agent.browsers.get("iab") -> Browser is not available: iab

    The remote browser runtime has valid current session and turn metadata, but the privileged IAB bridge is absent:

    hasNativePipe: false
bridgeType: undefined

    Chrome being discoverable in the same thread suggests that the general Browser runtime is functioning and the failure is specific to bridging/registering the Desktop IAB route into the Remote SSH-backed thread.

    Version mismatch ruled out

    The remote app-server had previously been long-running, so I replaced it with the app-bundled binary and verified the active process was launched from the current installation:

    /Applications/ChatGPT.app/Contents/Resources/codex \
  -c features.code_mode_host=true \
  app-server --listen unix://

    After reconnecting the existing Remote SSH thread, the result remained unchanged:

    agent.browsers.get("iab") -> Browser is not available: iab

    This rules out a stale standalone CLI/app-server version as the primary cause for this reproduction.

    Local vs Remote evidence

    Desktop logs from prior local-host sessions on the same installation family contain successful IAB startup and route registration events such as:

    browser_use_availability_resolved available=true browserPane=true reason=available
browser_use_iab_backend_startup_ready backend=iab
hostId=local

    The current Remote SSH-backed thread receives no IAB entry at all. This is consistent with the local browser sidebar/backend existing while its session-owned native route is not forwarded into the remote app-server tool runtime.

    This appears to be the same Remote SSH exposure problem tracked here, with an additional native-bridge signature related to #20678 and the previously reported __codexNativePipe symptom in #20248.

    Expected behavior remains either:

    1. expose the local Desktop IAB backend to the Remote SSH thread with the correct session ownership; or
    2. clearly mark IAB as unsupported for Remote SSH instead of mounting the Browser skill while iab is unavailable.

  5. nos1609 commented on Aug 22, 2026

    @nos1609
    nos1609
    on Aug 22, 2026 – with ChatGPT Codex Connector

    Adding a current Windows → Linux Remote SSH reproduction.

    Environment

    • ChatGPT/Codex Desktop: 26.818.5229.0
    • Local platform: Windows 11 on ARM64
    • Bundled Browser plugin: browser@openai-bundled 26.818.41509
    • Connection: Desktop Remote Connections / SSH
    • Remote host: headless Linux (XDG_SESSION_TYPE=tty)
    • Thread type: normal user thread

    Result

    The Desktop in-app browser sidebar is available, and the remote turn receives ambient browser metadata, including the open-tab count and current URL. However, the same turn receives no callable Browser control surface.

    The remote app-server reports all relevant feature flags enabled:

    in_app_browser = true
browser_use = true
browser_use_external = true
browser_use_full_cdp_access = true
computer_use = true

    But its browser-related MCP status is empty:

    cloudflare-browser: serverInfo=null, tools=[]
playwright:           serverInfo=null, tools=[]

    The callable tool inventory contains no Browser controller. A standalone Playwright MCP can expose browser commands on the Linux host, but it starts a separate browser and cannot attach to the authenticated Desktop IAB.

    A sanitized Desktop log also shows the browser sidebar associated with a placeholder local conversation while the route points at the Remote SSH thread:

    conversationId=client-new-thread:<redacted>
ownerRoutePath=/local/<remote-thread>?hostId=remote-ssh-discovered:<redacted>

    This appears to be the same session-owned IAB route exposure problem reported here. The additional inconsistency is that the remote agent is explicitly told that the Desktop browser and tabs exist, but is not given any tool capable of inspecting or controlling them.

    Expected behavior

    Either:

    1. expose the session-owned Desktop IAB backend to the Remote SSH thread; or
    2. do not inject ambient browser context or present the browser as usable, and show a clear explanation that Browser Use is host-local/unsupported for this session.

    No authenticated URL, browser content, host identity, thread identifier, or local path is included.

  6. linonetwo commented on Aug 28, 2026

    @linonetwo
    linonetwo
    on Aug 28, 2026

    Corroborating this on a current Remote SSH task.

    Environment

    • Codex CLI on the remote host: codex-cli 0.150.0-alpha.8
    • Remote runtime: Linux x86_64 (Debian 13 userland)
    • Connection: Codex Desktop Remote SSH / Remote Connections

    Current reproduction

    1. Open an in-app browser tab in Codex Desktop and navigate it to a test page.
    2. Open/use a task backed by the remote SSH host.
    3. Ask the remote agent to inspect and operate the already-open Desktop browser tab.
    4. The turn receives ambient browser context (open-tab count, current URL/title), but its callable tool surface contains no in-app-browser navigation, inspection, screenshot, or interaction tool.
    5. The agent therefore cannot demonstrate its browser actions in the user-visible Desktop tab and must fall back to a separate browser runtime on the remote host.

    This is not target-site reachability: the user-visible Desktop tab itself is open. It is the same bridge mismatch described here—read-only ambient IAB metadata crosses into the remote turn, while the corresponding callable controller does not.

    Expected

    A Remote SSH-backed task should be able to claim and operate its session-owned Desktop in-app browser tab so the user can watch and verify the same interaction. If that is intentionally unsupported, the app should clearly say so and should not inject browser-tab context that implies the agent can control it.

    No private URL, host identity, thread ID, credential, or project detail is included in this reproduction.

  7. antonincohen commented on Sep 2, 2026

    @antonincohen
    antonincohen
    on Sep 2, 2026

    Still reproducible on 2026-09-02 with a Desktop-managed Remote SSH task running codex-cli 0.151.0 on Linux x86_64.

    In a real authenticated admin workflow, the Desktop in-app Browser was open and working, and the remote turn received the open-tab count plus current URL. The task nevertheless received no Browser inspection or control surface: no page read, DOM/accessibility state, screenshot, navigation, click/type, node_repl/js, or IAB bridge. Local tasks on the same user setup can use the Browser.

    This also conflicts with the current official built-in-browser help article, which says the user and ChatGPT can see the same page and tells users to ask ChatGPT to use the current page; it does not document a Remote SSH exception:
    https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app

    A fuller current reproduction is also recorded in #34263. No private URL, credentials, page content, or customer data are included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions