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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   browser

   remote

   on Jul 20, 2026
2. github-actions commented on Jul 20, 2026

   

   github-actionsBot

   on Jul 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Desktop app silently fails to attach node_repl MCP tools to new tasks — breaks Browser (in-app), Chrome, and Computer Use; CLI with the same config works #33599
   • Windows: Chrome, Browser, and Computer Use mentions recognized but callable tools are not attached (26.707.12708.0) #33660
   • Browser and Chrome plugins are installed and enabled, but their control tools are not exposed to the task. #33625

   Powered by Codex Action
3. antonincohen commented on Jul 20, 2026

   

   antonincohen

   on Jul 20, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Reviewed the suggested duplicates:

   • Desktop app silently fails to attach node_repl MCP tools to new tasks — breaks Browser (in-app), Chrome, and Computer Use; CLI with the same config works #33599: macOS Desktop fails to attach node_repl to ordinary new/local tasks. In this report, Local tasks work reliably.
   • Windows: Chrome, Browser, and Computer Use mentions recognized but callable tools are not attached (26.707.12708.0) #33660: Windows-specific failure affecting Browser, Chrome, and Computer Use in local Desktop tasks.
   • Browser and Chrome plugins are installed and enabled, but their control tools are not exposed to the task. #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.
4. nepfaff commented on Aug 25, 2026

   

   nepfaff

   on Aug 25, 2026

   More actions

   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.
5. linonetwo commented on Aug 27, 2026

   

   linonetwo

   on Aug 27, 2026

   More actions

   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.
6. linonetwo commented on Aug 28, 2026

   

   linonetwo

   on Aug 28, 2026

   More actions

   Reproduced again on 2026-08-28 in a real browser-acceptance workflow. This is a product capability gap, not a security-vulnerability report.

   Environment

   • Codex Desktop-managed Remote SSH task (the exact Desktop build is not visible from the remote task)
   • Remote CLI/app-server: codex-cli 0.150.0-alpha.8
   • Remote host: Debian GNU/Linux 13 (trixie), x86_64; Linux 7.0.12

   Latest reproduction and impact

   1. The user opened the target application in a Codex in-app Browser tab and explicitly asked the Remote SSH task to use that visible tab for acceptance testing.
   2. The task received ambient UI state indicating that the tab existed and which page was selected.
   3. No Browser-tab inspection or control tool was available to the remote task: it could not read DOM/accessibility state, capture a screenshot, navigate, click, fill, or observe the result.
   4. The remote task had to install Chromium/Playwright and test in a separate browser process on the server.
   5. Those checks can validate HTTP/UI behavior, but they are disconnected from the authenticated Browser profile and from the tab the user is watching. The user cannot observe the agent's actions or directly review the exact resulting state, so this does not meet interactive acceptance-test requirements.

   Suggested authorization and UX boundary

   A Desktop-to-Remote bridge should be explicitly opt-in and scoped to a user-authorized task and tab:

   • Do not enumerate or expose other tabs by default.
   • After explicit authorization, expose structured DOM/accessibility snapshots, screenshots, navigation, click, scroll, and protected text-entry actions for that tab only.
   • Keep every action and resulting page state visibly synchronized in the same in-app Browser tab.
   • Provide an immediate stop/user-takeover control, preserve navigation history where possible, and keep an audit trail of agent actions without recording sensitive field values.
   • Continue to require confirmation for irreversible or externally consequential actions; tab authorization should not imply blanket authorization for those actions.
   • Revoke the bridge when the user closes the tab, revokes access, switches the task/host boundary, or the authorization expires.

   If this bridge is intentionally unsupported for Remote SSH, the composer and ambient browser context should clearly say that the tab is view-only for the remote task rather than implying that Browser Use is available.
7. linonetwo commented on Aug 29, 2026

   

   linonetwo

   on Aug 29, 2026

   More actions

   Additional real-world reproduction from Codex Desktop with a managed Remote SSH workspace (2026-08-29): the desktop user had an in-app browser tab open on a deployed trial site, and the remote task received ambient tab URL/title context, but the remote agent had no browser/node_repl tool capable of controlling that existing tab. Codex CLI 0.150.0-alpha.8 on the remote Linux host could run terminal-based API checks, and a separately downloaded Playwright Chromium could test the site headlessly, but neither path could drive the user-visible Codex App tab or show those interactions to the desktop user. This creates an important acceptance/audit gap: the user explicitly asked to watch the agent test the already-open tab, yet the agent could only provide off-screen screenshots and logs. Expected: a consent-gated bridge exposing the selected App browser tab to the remote task, with visible focus/action indicators and a clear read/write audit trail. Related symptom/overlap: #22844.
8. antonincohen commented on Sep 2, 2026

   

   antonincohen

   on Sep 2, 2026

   Author

   More actions

   Reproduced again on 2026-09-02 in a current real-world authenticated admin workflow.

   Environment

   • Codex Desktop-managed Remote SSH task
   • Remote Codex CLI/app-server: codex-cli 0.151.0
   • Remote host: Linux 6.17.0-1018-azure, x86_64
   • Normal user task; the in-app Browser was already open and authenticated

   Current result

   • The remote turn receives ambient UI state: two tabs are open and the current tab URL is supplied.
   • No callable Browser controller is provisioned: no current-page read, DOM/accessibility inspection, screenshot, navigation, click, scroll, protected form entry, node_repl/js, or equivalent IAB bridge.
   • The agent can search public web pages and run remote-host HTTP/API checks, but neither has access to the authenticated Desktop Browser session.
   • The same user reports that Local Codex tasks can read and operate the in-app Browser normally.

   This prevented the Remote SSH task from inspecting configuration in an authenticated third-party admin portal that was visibly open in the Codex Browser pane. No private URL, page content, credentials, or customer data are included here.

   Documentation discrepancy

   The current official help article says that with the built-in browser, “You and ChatGPT can see the same page,” and instructs the user to ask ChatGPT to use the current page:

   https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app

   The article does not identify Remote SSH as unsupported. Because the Desktop UI still exposes the Browser and sends ambient tab context into the remote task, the present behavior looks like a silent provisioning/bridge failure rather than an intentional, clearly communicated limitation.

   Expected remains: forward a consent-gated controller for the selected Desktop tab into the Remote SSH task, or explicitly mark the Browser pane as view-only/unsupported for that task and do not imply that the agent can use it.
9. Crokily commented on Sep 9, 2026

   

   Crokily

   on Sep 9, 2026

   More actions

   Additional reproduction on 2026-09-09.

   Reproduced a similar symptom with the macOS Codex desktop app 26.901.51231 (Build 8109) connected to a remote Linux ARM64 host over SSH (remote Codex CLI 0.153.4).

   Observed:

   • The app's browser pane can open and display a page served by the remote host through automatic port forwarding.
   • The remote task receives the selected browser tab's URL/context, including after explicitly mentioning the browser tab.
   • The remote task still has no browser interaction runtime or node_repl/js tool available. Opening/focusing the browser tab does not provide screenshot, click, or typing access to it.

   Additional isolation:

   • A temporary page served on the remote host loaded in the Mac app browser. Client-side DOM, canvas, storage, cookies, fetch, and reload checks worked. This shows that page execution and forwarding work; it does not establish that the agent control channel works.
   • Separately, screenshot-based interaction with Chromium on the remote Linux desktop succeeded using PyAutoGUI: typing, checkbox selection, button clicks, and scrolling. This operates the remote desktop, not the Mac app's embedded browser, and does not resolve the embedded-browser issue.

   The failure appears to be in availability of the browser interaction tools for this remote task; I have not established the underlying cause.

   Is browser interaction from SSH-backed tasks currently supported? If so, which diagnostics would help distinguish runtime provisioning from the app-to-remote control bridge?
10. Clauber commented on Oct 3, 2026

    

    Clauber

    on Oct 3, 2026

    More actions

    I’m also experiencing this with the Mac desktop app connected to a Linux host through Remote SSH. This same workflow worked for me until last week, so this appears to be a regression. I haven’t identified the exact update or change that triggered it.

    Environment

    • Mac desktop app: 26.930.31730 (build 12947)
    • Remote Codex CLI: codex-cli 0.160.0
    • Remote OS: Ubuntu 24.04 LTS, x86_64
    • Remote kernel: 6.17.13-2-pve
    • Connection: desktop app → Remote SSH → Linux host
    • Browser, Chrome, Computer Use, and unified-computer-use plugins installed and enabled on the Mac

    Observed behavior

    The in-app Browser loads pages normally, and the chat receives ambient browser context, including the current URL. However, the remote chat no longer has native browser-control tools available to inspect the page, click, or type. Explicitly requesting @Browser and retrying did not expose those tools.

    The remote host’s bundled plugin cache contains only visualize, while the browser-related plugins are present on the Mac. No native node_repl or cua_repl browser-control tools appear in the remote chat’s available tool inventory.

    This seems consistent with the desktop browser-control runtime no longer being provisioned or bridged into the remote session. I haven’t yet tested a local Mac chat as a comparison.

    Is there a known recent regression affecting browser control in Remote SSH chats, or a recommended recovery procedure? Happy to provide targeted, sanitized diagnostics.

    👍React with 👍1Reacted by Timothy Hubbard