[macOS Desktop] In-app Browser control unavailable because bundled node_repl MCP client never becomes ready #38549

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

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   browser

   on Aug 14, 2026
2. github-actions commented on Aug 14, 2026

   

   github-actionsbot

   on Aug 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Remote HTTP MCP servers: handshake OK but tools never exposed in desktop conversations (regression in 26.803.61601/81509) #37976

   Powered by Codex Action
3. andrsksr commented on Aug 15, 2026

   

   andrsksr

   on Aug 15, 2026

   More actions

   Additional reproduction from macOS, observed during a long-running end-to-end product test.

   Environment:

   • Codex Desktop 26.810.41047 (build 6570)
   • macOS 26.3 (25D125), Apple Silicon arm64
   • Bundled Browser and Chrome plugin cache: 26.810.41047

   Timeline:

   • Browser control was stable for several weeks through August 13, 2026.
   • The failure began on August 14, 2026, without an intentional configuration change.

   Observed behavior:

   • The in-app Browser renders the page normally.
   • The Browser backend discovers the exact visible tab and returns its URL and provider tab identifier.
   • Claiming or attaching to that tab then times out after approximately 15 seconds, so inspection, clicks, typing, screenshots, and navigation through the control API are unavailable.
   • The Chrome backend is also only partially functional: tab listing or opening can succeed, while tab selection, retrieval, and closing time out.
   • The site itself remains reachable and authenticated. The failure is isolated to the browser-control handoff.

   Recovery attempts without durable success:

   • Full restarts of Codex Desktop, Chrome, and macOS
   • New browser tabs and a separate Chrome profile
   • Reloading the Chrome extension
   • Closing unnecessary tabs
   • Pruning stale Browser and Computer Use worker processes before retrying

   Impact:
   This blocks a production-like end-to-end test that requires an owner session in Chrome and a member session in the in-app Browser. The application under test remains healthy; only the Codex browser-control layer is unavailable.

   This appears closely related to this issue, although the failure point in this reproduction is slightly later: the browser tooling is exposed and the backend can discover the visible tab, but it cannot claim or control it. No private URLs, account identifiers, or page contents are included here.
4. Dean1991911 commented on Aug 15, 2026

   

   Dean1991911

   on Aug 15, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional reproduction from macOS

   Observed during a long-running end-to-end product test.

   Environment

   • Codex Desktop 26.810.41047 (build 6570)
   • macOS 26.3 (25D125), Apple Silicon arm64
   • Bundled Browser and Chrome plugin cache: 26.810.41047

   Timeline

   • Browser control was stable for several weeks through August 13, 2026.
   • The failure began on August 14, 2026, without an intentional configuration change.

   Observed behavior

   • The in-app Browser renders the page normally.
   • The Browser backend discovers the exact visible tab and returns its URL and provider tab identifier.
   • Claiming or attaching to that tab then times out after approximately 15 seconds, so inspection, clicks, typing, screenshots, and navigation through the control API are unavailable.
   • The Chrome backend is also only partially functional: tab listing or opening can succeed, while tab selection, retrieval, and closing time out.
   • The site itself remains reachable and authenticated. The failure is isolated to the browser-control handoff.

   Recovery attempts without durable success

   • Full restarts of Codex Desktop, Chrome, and macOS
   • New browser tabs and a separate Chrome profile
   • Reloading the Chrome extension
   • Closing unnecessary tabs
   • Pruning stale Browser and Computer Use worker processes before retrying

   Impact

   This blocks a production-like end-to-end test that requires an owner session in Chrome and a member session in the in-app Browser. The application under test remains healthy; only the Codex browser-control layer is unavailable.

   This appears closely related to this issue, although the failure point in this reproduction is slightly later: the browser tooling is exposed and the backend can discover the visible tab, but it cannot claim or control it.

   No private URLs, account identifiers, or page contents are included here.
5. vemelianov-aplus commented on Aug 24, 2026

   

   vemelianov-aplus

   on Aug 24, 2026

   More actions

   Additional reproducible data point from macOS, specifically involving an existing thread.

   Environment:

   • macOS 26.5.2, Apple Silicon (arm64)
   • Codex/ChatGPT Desktop 26.818.61809 (build 7019)
   • Bundled Browser plugin 26.818.61809
   • Thread ID: 01a03285-260b-7ce3-bebd-7a6070d9afa1

   Observed sequence:

   1. Continued an existing Codex thread that had not started with Browser attached.
   2. Selected and sent [@Browser](plugin://browser@openai-bundled) from the UI.
   3. The Browser skill/instructions were injected successfully, and the app explicitly reported the Browser plugin capability.
   4. The active task still did not expose mcp__node_repl__js; tool discovery contained no node_repl entry.
   5. A subsequent turn with Browser explicitly attached had the same result, so the agent could not bootstrap browser-client.mjs or control the in-app browser.

   Local installation checks:

   • browser-client.mjs exists in the bundled plugin cache.
   • App and Browser plugin versions match.
   • Desktop logs report browser_use_runtime_paths_selected with bundled node_repl, Node v24.19.0, and nodeVersionStatus=ok.
   • The failure is therefore at tool/runtime attachment: the UI and skill layer recognize Browser, but the callable node_repl bridge is absent from the task.

   Expected behavior:

   Attaching Browser to an existing thread should either expose the required node_repl tool on the next turn, or the UI should clearly state that the thread must be recreated. A selectable plugin mention should not produce a skill-only state with no executable control tool.

   No private URLs, repository contents, credentials, or raw logs are included.
6. Dean1991911 commented on Aug 31, 2026

   

   Dean1991911

   on Aug 31, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   New recurrence on 26.820.60940; bundled signatures are valid

   This issue has recurred after a previous reinstall temporarily restored Browser control.

   Environment

   • ChatGPT/Codex Desktop 26.820.60940 (build 7119)
   • macOS 26.6.2 (build 25G83)
   • Apple Silicon (arm64)
   • Bundled Browser plugin 26.820.60940
   • Bundled Node v24.19.0

   Current behavior

   • The in-app Browser renders the current page normally.
   • The Browser skill is present, but the task does not receive mcp__node_repl__js, so the page cannot be inspected or controlled.
   • Logs show the expected bundled runtime paths and a successful backend startup:
     • browser_use_runtime_paths_selected ... nodeVersionStatus=ok
     • browser_use_iab_backend_startup_ready
   • Tool attachment then repeatedly fails with:
     • browser-use native pipe rejected socket peer reason=missing-code-signing-identity
     • dynamic_app_tools_peer_rejected reason=missing-code-signing-identity

   Important signing check

   The error does not appear to be caused by damaged or unsigned bundled files. Verification performed outside the task sandbox succeeds for all relevant binaries:

   • /Applications/ChatGPT.app: valid on disk
   • Bundled node_repl: valid on disk
   • Bundled Node: valid on disk
   • Bundled codex: valid on disk
   • Signing authority: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

   This narrows the failure to runtime peer-identity lookup/authorization or task-tool attachment, rather than app-bundle corruption.

   Recurrence pattern

   • Browser control previously recovered after reinstalling the desktop app.
   • The same failure later returned on a newer desktop/plugin version.
   • Full app restarts and new tasks do not reliably recover the missing tool.
   • Reinstallation is therefore not a durable fix.

   Expected behavior: the correctly signed bundled helper should be recognized by the native pipe and the Browser control tool should be attached to every Browser-enabled task.

   No private URLs, page contents, account identifiers, or raw logs are included. Please let me know if a specific redacted diagnostic bundle or subsystem log would help isolate the peer-identity failure.
7. pbeens commented on Sep 6, 2026

   

   pbeens

   on Sep 6, 2026

   More actions

   Additional reproduction on ChatGPT/Codex Desktop 26.901.51231

   I am seeing what appears to be the same or a closely related browser-control failure on the current macOS desktop release.

   Environment

   • macOS, Apple Silicon
   • ChatGPT/Codex Desktop 26.901.51231, released Sep 5, 2026
   • Bundled Browser plugin 26.901.51231
   • Browser plugin is explicitly enabled in ~/.codex/config.toml:

   [plugins."browser@openai-bundled"]
   enabled = true

   • browser-client.mjs is present at:

   ~/.codex/plugins/cache/openai-bundled/browser/26.901.51231/scripts/browser-client.mjs
   

   Observed behaviour

   Browser functionality appears to be partially available.

   1. In a fresh Codex task, I asked Browser to open example.com and report the page title. This succeeded and returned “Example Domain.”
   2. I then asked Browser to click the “More information...” link and report the resulting page title. This also succeeded, returning “Example Domains.”
   3. I opened a Google Form using the in-app Browser and asked Codex to inspect it without making changes. This succeeded. It correctly identified the form's editable question and all four radio-button choices.
   4. I then asked it to select one of those radio-button choices without submitting the form.
   5. Codex responded:

   “I can’t confirm the selection because browser interaction controls aren’t available in this session. No form information was changed or submitted.”

   1. A second attempt to select another option produced the same browser-interaction-controls error.
   2. I then explicitly invoked [@Browser](plugin://browser@openai-bundled) and asked it to select the option. Codex then responded:

   “I can’t choose the option because the Browser plugin isn’t available in this session.”

   Additional observations

   • The in-app Browser panel itself opens and renders the Google Form correctly.
   • Browser can read/inspect the form and enumerate its controls.
   • Browser can successfully perform at least some navigation/click interaction on a simple page such as example.com.
   • Interaction with the Google Form control fails because the browser interaction tools are reported as unavailable.
   • After the interaction failure, explicitly invoking Browser can result in the plugin itself being reported unavailable in the same session.
   • ChatGPT Settings → Browser has also displayed “In-app browser plugin unavailable.”

   This suggests the Browser skill/plugin and rendering layer are available, but the interactive control bridge/tool attachment is either incomplete or becoming unavailable within the task.

   I can provide additional diagnostics or logs if there is a specific command or log location that would be useful.