›_ Codex Issues
Codex Issues / #34263

macOS Desktop: Browser/node_repl tools are not provisioned to Remote SSH tasks

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

Summary

The bundled Browser works from a Local Codex task in the macOS desktop app, but tasks running on Linux hosts through the desktop app's Remote SSH connection are not provisioned with the Browser runtime or the required node_repl/js tool.

The right-side in-app browser can be opened manually and its ambient URL is visible to the remote task, but the remote task cannot navigate, inspect, click, scroll, or read the page.

Environment

  • Desktop client: macOS ChatGPT/Codex desktop app
  • Browser bundle observed in a working Local task: openai-bundled/browser/26.715.21425
  • Remote Codex CLI: codex-cli 0.144.6
  • Remote OS: Ubuntu Linux 6.8 x86_64
  • Reproduced on two separate Linux Remote SSH hosts
  • Same desktop app, account, and authenticated built-in Browser profile in all tests

Reproduction

  1. In the macOS desktop app, enable/install the bundled Browser plugin and sign in to a website in the built-in browser.
  2. Start a Local Codex task.
  3. Ask Codex to use the built-in browser.
  4. The Local task exposes node_repl/js, imports browser-client.mjs, connects with agent.browsers.get("iab"), and can navigate/read the page.
  5. Start a task on a saved Linux Remote SSH host in the same desktop app.
  6. Open the right-side built-in browser and ask the remote task to inspect or navigate it.
  7. Tool discovery in the remote task exposes no node_repl/js and no Browser control tool. The remote filesystem also has no bundled Browser client.
  8. Starting a fresh Remote SSH task does not change the result.

The Local task can use the authenticated Browser profile successfully. The Remote SSH task can only see ambient UI state such as the current URL and cannot control the page.

Expected behavior

A Remote SSH task opened from the desktop app should receive a bridge to the desktop app's local built-in Browser while its shell and filesystem operations continue to run on the remote host.

If Browser control is intentionally unsupported for Remote SSH tasks, the app and Browser documentation should state that clearly and the task should report a specific unsupported-surface error.

Actual behavior

The Browser pane is visible to the user and ambient browser state is supplied to the remote task, which implies integration, but the execution bridge required to act on that state is absent. The failure is silent: the model simply has no Browser or node_repl tool.

Workaround

Delegate the browser-only step to a separate Local task, then relay extracted data back to the Remote SSH task. This works but is fragile for scheduled workflows, durable state, approvals, and task continuity.

Related issues

This appears to be the macOS Remote SSH equivalent of the tool-provisioning failures reported in:

  • #19365
  • #21575

Those reports involve Windows/WSL, but the key symptom is the same: Browser is installed/enabled while the active non-local task does not receive node_repl/js or the IAB bridge.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33599
  • #33660
  • #33625

Powered by Codex Action

antonincohen · 1 month ago

Reviewed the suggested duplicates:

  • #33599: macOS Desktop fails to attach node_repl to ordinary new/local tasks. In this report, Local tasks work reliably.
  • #33660: Windows-specific failure affecting Browser, Chrome, and Computer Use in local Desktop tasks.
  • #33625: plugin/tool attachment failure in a normal Desktop task; it does not identify Remote SSH as the trigger.

I also searched the repository for Remote SSH + Browser/node_repl reports. #26560 is remote-control related, but it has a different failure mode: node_repl is attached and launches with the wrong controller-side environment. Here, Remote SSH tasks receive no Browser/node_repl tool at all, while a Local task in the same macOS Desktop app works.

Keeping this issue open because the Remote SSH boundary is the distinguishing and reproducible trigger.

nepfaff · 2 days ago

Reproduced on a newer release with an SSH-backed Linux devcontainer.

Environment:

  • Codex Desktop on macOS: 26.820.60940
  • Remote Codex CLI/app-server: 0.149.1
  • Desktop Remote SSH connects to a Linux host whose codex app-server is launched inside an existing Docker devcontainer
  • Local Mac tasks can use @Browser successfully

Remote-task results:

  • The in-app browser pane works and the task receives ambient state such as the open-tab count and current URL.
  • @Browser is unavailable.
  • No node_repl/js or Browser-control tool is provisioned.
  • The remote bundled-plugin snapshot contains no browser@openai-bundled or chrome@openai-bundled.
  • browser_use, in_app_browser, computer_use, and full-CDP feature flags are enabled.
  • codex doctor reports the app-server, configuration, authentication, and WebSocket connection as healthy.
  • App-server logs contain no Browser initialization failure; the Browser runtime appears never to be attached.
  • Multiple fresh Remote SSH tasks reproduce it.

Since this also occurs on ordinary Remote SSH hosts, Docker does not appear to be the root cause. The devcontainer setup confirms that redirecting the remote app-server through docker exec does not receive a bridge to the Mac session-owned IAB backend.

Expected behavior remains either:

  1. bridge the Desktop IAB backend into the Remote SSH task; or
  2. clearly mark @Browser as unsupported and avoid injecting ambient browser state that the task cannot act upon.
linonetwo · 19 hours ago

Additional reproduction on a newer Remote SSH task, with one product/security detail that seems important for the expected fix.

Environment

  • Desktop side: Codex Desktop on Windows, exact Desktop build is not visible from the remote task
  • Remote connection: Desktop-managed Remote SSH task
  • Remote CLI/app-server: codex-cli 0.150.0-alpha.8
  • Remote host: Debian GNU/Linux 13 (trixie), x86_64
  • Kernel exposed by the remote environment: Linux 7.0.12-arch1-1

Reproduction

  1. In Codex Desktop, the user opens an authenticated page in the built-in Browser and mentions that visible tab in a Remote SSH task.
  2. Ask the remote task to inspect and interact with the same visible tab.
  3. The task receives ambient tab state, and its tool registry exposes codex_app__open_in_codex. That tool can show/open a URL or target a tab in the Codex UI, but explicitly is not an inspection or interaction interface.
  4. The task receives no callable Browser bridge: no click/type/fill, DOM or accessibility-tree read, screenshot, current-tab read, or equivalent node_repl/browser-client tool.
  5. The task can therefore display a URL to the user, but cannot verify login state, operate the page, or show the user the results of agent actions in that same tab.

This matches the Remote SSH provisioning boundary described in this issue. It reproduces on Windows Desktop + Debian remote as well as the macOS + Linux configurations already reported.

Impact / workaround

For browser-based acceptance testing, the remote task must separately download and run Playwright/Chromium on the remote host. That is slow, consumes remote storage, and creates a different browser profile/session from the authenticated tab the user is watching. It does not satisfy workflows where the user wants to observe and review actions in the existing Codex Browser tab.

Expected security and UX contract

Please provide a controlled, auditable bridge for the current user-authorized tab while shell/filesystem work remains remote. At minimum it should support page read/DOM or accessibility inspection, screenshot, click, type/fill, and navigation on the explicitly authorized tab.

Sensitive values typed into forms should be passed as protected tool arguments, not embedded in URLs, model-visible logs, or diagnostic output. Agent actions and their resulting page state should remain visible to the user in that same Codex Browser tab.

If bridging the Desktop-owned tab into Remote SSH tasks is intentionally unsupported, the app should clearly say so and should not imply controllability merely by supplying ambient tab state plus open_in_codex.