[Windows] Bundled Browser/Chrome/Computer Use plugins enabled in config but not exposed as callable tools

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

• #26006
• #26004
• #26113
• #25809
• #26078

Powered by Codex Action

I am sorry, I don't know if this is useful or the correct place to add this, but I got a similar problem, so asked the agent to describe everything we tried in a useful format so it could be used to address the issue, because it was working like a charm before one of the latest updates. Hope this helps, thanks in advance.

Additional reproduction / diagnostic data:

I am seeing the same class of issue where the in-app browser is open and manually usable, but Codex does not receive any callable browser-control tools.

Things tried:

• Fully quit/restarted the Codex desktop app.
• Opened the in-app browser manually.
• Confirmed the browser panel is visible/usable manually.
• Asked Codex to discover browser/in-app-browser tools in the existing thread.
• Forked the existing thread into a fresh same-directory thread and repeated the tool discovery check.
• Created/continued in a new thread after the full app restart and repeated the tool discovery check.
• Reopened/kept the in-app browser panel open and repeated the discovery check again.

Tool discovery queries included variants like:

• in app browser browser control open navigate screenshot click
• Codex in-app browser control navigate click type screenshot DOM inspect current tab browser
• in-app browser browser open current tab navigate click type screenshot inspect DOM playwright

Observed result:

tool_search returned Codex app/thread-management tools only, for example:

• codex_app.read_thread
• codex_app.fork_thread
• codex_app.create_thread
• codex_app.send_message_to_thread
• codex_app.handoff_thread
• codex_app.get_handoff_status
• codex_app.list_threads
• codex_app.automation_update
• codex_app.set_thread_title
• codex_app.set_thread_pinned
• codex_app.set_thread_archived

Expected browser-related tools were not exposed at all. Missing capabilities included:

• browser navigation / opening current tab
• click
• type
• screenshot
• DOM inspection
• Playwright/browser session controls
• any callable browser, chrome, or in-app-browser namespace/function

Important detail: this did not change after fully restarting Codex, opening the browser manually, forking the thread, or creating/continuing in a fresh thread after restart.

This looks like the failure is occurring before browser backend attachment. The Browser/In-App Browser capability does not appear to be injected into the model/tool runtime at all, even though the in-app browser panel is open and usable by the user.

With the recent update it got fixed, idk if it was a one time thing, but anyway thank you so much for the great work, I am loving using the codex desktop app to work!

Plugin state needs separate lifecycle fields: installed, enabled in config, authenticated if needed, initialized, tools listed, schemas accepted, callable in current thread, and hidden reason. Browser/Chrome/Computer Use can then show enabled_but_not_callable with the exact failing transition instead of appearing healthy in the plugin UI.

---

_Generated with ax._

Draft Comment For openai/codex#26133

I have another Windows reproduction in the same failure family, with a possible non-default CODEX_HOME / split-home angle.

Environment:

• Codex Desktop package currently running: OpenAI.Codex_26.623.5175.0_x64
• Windows: Windows 11 Pro, 10.0.26200, 64-bit
• Active CODEX_HOME: non-default drive, E:\codex-home
• Old default home C:\Users\<user>\.codex: still exists as a normal directory, not a junction
• Shell codex command: npm/global wrapper reports codex-cli 0.128.0
• Bundled Browser/Chrome/Computer Use plugin cache: 26.608.12217
• Active config has these enabled:

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

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

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

Observed behavior:

• Computer Use is installed/enabled and the plugin files exist locally, including scripts/computer-use-client.mjs.
• The bundled cua_node runtime exists locally, including node_repl.exe.
• The current session does not expose mcp__node_repl__js, node_repl/js, js, or an equivalent JS execution tool after tool discovery.
• Because the required JS tool is absent, Computer Use cannot reach the bootstrap stage where computer-use-client.mjs initializes sky, nodeRepl.nativePipe, or sky.list_apps().
• codex mcp list from the shell CLI only shows an external GitHub MCP server; there is no active external node_repl MCP server in the current config.
• From the shell CLI wrapper only, --enable js_repl / --enable js_repl_tools_only did not cause any JS tool to appear, and the feature probe still reported both as removed false. I have not verified the Desktop app-server's internal feature state.

Path / migration evidence:

• The active Codex home is on E:, but stale C-home state still exists.
• Chrome native messaging registry currently points to a manifest whose path launches the extension host from C:\Users\<user>\.codex\plugins\cache\....
• E-home native-host metadata points to E:\codex-home\plugins\cache\..., so registry/AppData/E-home state disagree.
• This looks related to #26732; in a later follow-up there, the reporter said moving Codex-related files back to C: and rebooting fixed the missing node_repl symptom.
• I am not claiming the drive location is definitively the root cause. The official CODEX_HOME docs do not say Windows state must be on C:. But the combination of this local split-home evidence plus #26732 suggests maintainers may want to check non-default CODEX_HOME, stale default-home directories, junction/symlink behavior, and cross-drive plugin/runtime path handling during tool injection.
• I am not planning to test moving this setup back to C:, because that is too disruptive for this machine. I can provide the current redacted state instead.

Why this seems to belong in this issue:

• The failing transition is not Telegram/Chrome/app-specific.
• The failure occurs before Computer Use can bootstrap and before any nativePipe/Sky call can run.
• The installed/enabled plugin state exists, but the conversation tool runtime does not inject the required node_repl/js execution surface.

Useful discriminator for triage:

• If no node_repl/js tool is exposed at all, this aligns with this issue and possibly #30191.
• If node_repl/js becomes exposed but nodeRepl.write("ok") fails, this likely moves to the sandbox metadata issues such as #30249 / #29338 / #29303.
• If node_repl/js works but computer-use-client.mjs lacks nodeRepl.nativePipe, this aligns more specifically with #30191.

I can provide redacted follow-up evidence if useful:

• Narrow config/plugin cache excerpts.
• Tool discovery output from a fresh thread.
• Path-shape evidence for CODEX_HOME, default .codex, and Chrome native-host registration.
• Narrow logs around plugin registration / MCP startup / tool injection, with auth, cookies, tokens, and unrelated local paths removed.