Summary
On Windows Codex Desktop, the Chrome plugin and shared browser automation bridge are unstable. The Chrome plugin can sometimes open a basic HTTPS page and read the title, but it is very slow and unreliable; direct browser-client setup calls hang until timeout. The Codex plugin UI also cannot uninstall the bundled Chrome plugin.
Environment
- OS: Windows
- Codex Desktop package:
OpenAI.Codex_26.506.2212.0_x64
- Plugin:
chrome@openai-bundled 0.1.7
- Chrome extension ID:
hehggadaopoacecdllhhajmbjkdcmajg
- Chrome extension version:
1.1.4_0
- Chrome plugin config:
[plugins."chrome@openai-bundled"] enabled = true
- Current browser backends exposed in the turn metadata:
["chrome", "iab"]
Reproduction
- Restart Codex Desktop.
- Enable the bundled Chrome plugin in Codex plugins settings.
- Ask Codex:
@chrome open https://example.com and read the page title
- Observe that it can sometimes succeed, but one run took about
1m50s for a trivial page title read.
- Ask Codex to inspect Chrome bookmarks:
@chrome can you view my bookmarks directory?
- It reports that the Chrome plugin/tool is unavailable for that task.
- In Codex plugin settings, attempt to uninstall the Chrome plugin.
- The UI shows a toast in Chinese:
插件卸载失败 (Plugin uninstall failed).
Direct diagnostics
From the agent-side Node REPL / browser-client path:
- Importing the Chrome plugin
browser-client.mjs succeeds quickly (~47ms).
- Calling
setupAtlasRuntime({ globals }) for the Chrome plugin hangs until tool timeout (120s).
- Calling
setupAtlasRuntime({ globals, backend: "iab" }) for the in-app browser backend also hangs until timeout (120s), so the issue may be in the shared browser-use/native pipe bridge, not only the Chrome extension.
- The current turn metadata includes:
{
"x-codex-browser-use-available-backends": ["chrome", "iab"]
}
Local health checks that pass
The plugin-provided diagnostic scripts report that the local pieces are present:
- Chrome is installed and running.
- The Codex Chrome Extension is installed and enabled.
- The native host manifest exists and points to the bundled Chrome plugin
latest extension host.
- The expected extension origin is allowed.
Relevant log lines
The Codex Desktop logs contain repeated plugin uninstall failures:
failed to uninstall plugin: failed to remove existing plugin cache entry: 拒绝访问。 (os error 5)
They also contain browser/IPC instability:
IpcRouter Socket error: write EPIPE
app_server_connection.state_changed ... next=disconnected
There are also bundled plugin cache install/update warnings on Windows:
bundled_plugins_marketplace_install_failed
errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to install plugin: failed to back up plugin cache entry: 拒绝访问。 (os error 5)"
Expected behavior
@chrome setup should initialize reliably or fail fast with a clear error.
- Browser automation setup should not hang until the outer
120s tool timeout.
- The Chrome plugin should reliably handle simple page tasks such as opening
https://example.com and reading the title.
- The plugin UI should either uninstall the plugin or clearly explain that bundled plugins cannot be uninstalled.
- If Chrome bookmarks /
chrome:// internal pages are intentionally unsupported, the model/plugin should report that limitation directly rather than implying the Chrome plugin/tool is unavailable.
Actual behavior
- Simple page-title reading can work, but is very slow and unreliable.
- Direct setup calls for both Chrome and IAB browser backends hang until timeout.
- The Chrome plugin UI uninstall flow fails with a generic toast.
- Logs point to Windows file-lock/access-denied failures and IPC disconnection.
Related issues checked
This appears related to other Windows browser/app-server issues, but this report includes the Chrome plugin and plugin uninstall failure combination:
Summary
On Windows Codex Desktop, the Chrome plugin and shared browser automation bridge are unstable. The Chrome plugin can sometimes open a basic HTTPS page and read the title, but it is very slow and unreliable; direct browser-client setup calls hang until timeout. The Codex plugin UI also cannot uninstall the bundled Chrome plugin.
Environment
OpenAI.Codex_26.506.2212.0_x64chrome@openai-bundled0.1.7hehggadaopoacecdllhhajmbjkdcmajg1.1.4_0[plugins."chrome@openai-bundled"] enabled = true["chrome", "iab"]Reproduction
1m50sfor a trivial page title read.插件卸载失败(Plugin uninstall failed).Direct diagnostics
From the agent-side Node REPL / browser-client path:
browser-client.mjssucceeds quickly (~47ms).setupAtlasRuntime({ globals })for the Chrome plugin hangs until tool timeout (120s).setupAtlasRuntime({ globals, backend: "iab" })for the in-app browser backend also hangs until timeout (120s), so the issue may be in the shared browser-use/native pipe bridge, not only the Chrome extension.{ "x-codex-browser-use-available-backends": ["chrome", "iab"] }Local health checks that pass
The plugin-provided diagnostic scripts report that the local pieces are present:
latestextension host.Relevant log lines
The Codex Desktop logs contain repeated plugin uninstall failures:
They also contain browser/IPC instability:
There are also bundled plugin cache install/update warnings on Windows:
Expected behavior
@chromesetup should initialize reliably or fail fast with a clear error.120stool timeout.https://example.comand reading the title.chrome://internal pages are intentionally unsupported, the model/plugin should report that limitation directly rather than implying the Chrome plugin/tool is unavailable.Actual behavior
Related issues checked
This appears related to other Windows browser/app-server issues, but this report includes the Chrome plugin and plugin uninstall failure combination: