Codex Desktop shows Chrome as connected, but @chrome automation tool is unavailable on Windows

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

• #21791
• #21916
• #21698
• #21878
• #21598

Powered by Codex Action

I am seeing the same class of problem on Windows, but with a bit more local evidence that may help narrow down where the bridge is failing.

Environment

• Platform: Windows x64
• Codex Desktop AppX package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
• Electron/internal app version found in app.asar package metadata: openai-codex-electron 26.519.41501
• Running Codex process crashpad annotation also shows _version=26.519.41501
• Embedded CLI version recorded in state_5.sqlite for the thread: 0.133.0-alpha.1
• Model: gpt-5.5
• Chrome plugin manifest in the bundled package and local cache: chrome@openai-bundled version 26.519.41501
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome extension version detected locally: 1.1.5_0

What the UI shows

Codex settings / Computer Control shows Google Chrome as connected, with the localized text equivalent of:

Connected to browser extension; more controls are available

The “Any app” / broader computer-control entry is disabled with text equivalent to:

Disabled by your organization, or unavailable in your region

Local checks that pass

From the plugin diagnostics under:

C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\scripts

these checks pass:

• chrome-is-running.js --json reports Chrome running.
• check-extension-installed.js --json reports the Codex Chrome Extension installed and enabled in the selected profile (Profile 1).
• check-native-host-manifest.js --json reports the native messaging manifest is correct.
• The native host manifest points at:

C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

• extension-host.exe is actually running, launched by Chrome native messaging from the same chrome\latest\extension-host path.
• extension-host-config.json contains a valid browserClientPath:

{
  "browserClientPath": "C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\scripts\\browser-client.mjs",
  "codexCliPath": "C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\app-server-runtime\\codex",
  "nodePath": "C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\app-server-runtime\\node",
  "nodeReplPath": "C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\app-server-runtime\\node_repl"
}

What fails

Even after fully restarting Codex and starting a new thread, mentioning:

@chrome open bilibili

or similar does not give the agent any usable Chrome automation surface.

Inspecting the local Codex state DB for the new thread shows that thread_dynamic_tools only contains:

automation_update
read_thread_terminal
load_workspace_dependencies

There is no node_repl/js tool, no Chrome tab/context tool, and no browser-client control surface injected into the model turn.

So the failure does not appear to be that Chrome, the extension, native messaging, or the local cached plugin files are missing. Those pieces are present and connected. The issue appears to be that the Codex workspace thread does not receive the Chrome control execution layer even though the Chrome integration is connected.

Why this may be different from a simple stale-cache issue

The AppX package version is 26.519.5221.0, while the Electron app internal version and the bundled Chrome plugin manifest both report 26.519.41501. This looks like two versioning schemes rather than necessarily a stale cache, because the packaged app.asar itself contains openai-codex-electron version 26.519.41501.

The more actionable mismatch is:

• native host config has browserClientPath
• Chrome native host is running
• extension is connected
• but new workspace threads do not receive node_repl/js / browser-client tools

Expected behavior

If Codex settings says Chrome is connected and “more controls are available”, a new @chrome workspace thread should receive the Chrome browser-client execution surface needed for navigation/control, or the UI should clearly explain why that surface is gated/unavailable.

Actual behavior

Chrome appears connected in the UI, native host diagnostics pass, but @chrome only loads descriptive plugin/skill context. The model cannot navigate, list tabs, click, or otherwise control Chrome because the execution tools are not injected into the thread.