›_ Codex Issues
Codex Issues / #22844

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

Open 💬 5 comments Opened May 15, 2026 by neilsanghrajka

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:

  • #21326: repeated remote connection selection/reconciliation plus Browser Use native pipe/sidebar initialization
  • #20399: Remote connections can mix project/thread host state
  • #19590: SSH remote can tunnel to the wrong app-server
  • #22187: Remote Connections sessions do not inject the same context as remote CLI

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.

View original on GitHub ↗

5 Comments

splitice · 2 months ago

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.

nbros · 1 month ago

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

Turtle-Hwan · 29 days ago

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.
nos1609 · 5 days ago

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.

linonetwo · 8 hours ago

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.