›_ Codex Issues
Codex Issues / #30170

Codex Desktop background suggestion task unexpectedly launches automated Chrome window

Open 💬 2 comments Opened Jun 26, 2026 by imsunhao

Codex Desktop unexpectedly opened an external Google Chrome window showing:

Chrome is being controlled by automated test software

I did not explicitly request browser automation, Chrome control, Playwright/Selenium, or any web task in the visible chat. This made it look like my computer had been remotely controlled or compromised.

Local investigation showed the Chrome process was launched by Codex:

Codex.app
  -> codex app-server
    -> npm exec chrome-devtools-mcp@latest
      -> chrome-devtools-mcp
        -> Google Chrome --enable-automation --remote-debugging-pipe --user-data-dir=~/.cache/chrome-devtools-mcp/chrome-profile about:blank

The related internal/background thread appeared to be:

thread_id: 019f01e2-c323-75b0-9106-ce8bb9b7a6f2
turn_id:   019f01e2-c370-7742-870e-af4d90e015aa
time:      2026-06-26 11:04:26 Asia/Shanghai
cwd:       /
model:     gpt-5.4

The prompt/log content began with:

Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this Projectless chat

This looks like a background personalized suggestion task, not a user-visible chat action. Around the same time, the logs show it loaded chrome-devtools tools, and then an external automated Chrome window appeared.

Expected behavior:

  • Background suggestion tasks should not launch visible external Chrome windows.
  • Browser automation should require explicit user intent or be clearly surfaced in the UI.
  • If Chrome automation is needed, use an isolated/in-app/headless flow or show a clear Codex-owned permission/notification before launching.
  • The user should be able to trace which visible thread/task launched browser automation.

Impact:

This is alarming from a security and trust perspective. A visible automated Chrome window appearing without user action makes it look like the machine has been compromised.

Environment details observed locally:

Codex Desktop app server started chrome-devtools-mcp via:
npm exec chrome-devtools-mcp@latest

Chrome launch args included:
--enable-automation
--remote-debugging-pipe
--user-data-dir=/Users/sunhao/.cache/chrome-devtools-mcp/chrome-profile
about:blank

Please treat this as a trust/safety UX regression even if the underlying process is expected internally.

View original on GitHub ↗

2 Comments

comeran · 2 months ago

Adding one more data point from #30177, which looks like the same underlying issue but with a slightly different Chrome behavior.

In my case, the background/context-aware suggestions task did not open a separate automated Chrome window. Instead, because my Codex config had Chrome DevTools MCP configured with --autoConnect, the hidden suggestions task appeared to connect to the existing Chrome remote debugging endpoint and triggered a Chrome remote debugging permission prompt after the visible task had already ended.

Observed local chain:

Hidden/background prompt:
Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this local project...

Same timestamp:
Codex.app -> codex app-server -> npm exec chrome-devtools-mcp@latest --autoConnect

Relevant config shape:

[mcp_servers.chrome-devtools]
type = "stdio"
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]

So the shared root problem seems to be: context-aware/background suggestion tasks can initialize browser-control MCP servers without a visible user request or clear attribution. The externally visible symptom may be either:

  • a new automated Chrome window, as reported here; or
  • a remote debugging permission prompt against an existing Chrome instance, as in #30177.

I am closing #30177 as a duplicate of this issue, but wanted to preserve this --autoConnect/existing-Chrome variant because it affects the permission and attribution UX.

cyenxchen · 2 months ago

Adding another data point for the existing-Chrome remote debugging prompt variant.

What I saw:

<img width="1096" height="110" alt="Image" src="https://github.com/user-attachments/assets/5c96b63c-b221-41f2-9512-227792ef81ca" />

  • Without any explicit Codex/browser-control conversation in the visible thread, Chrome showed the remote debugging infobar in Chinese: “Codex”已开始调试此浏览器, with a 取消 button.
  • This appeared on my regular Chrome window, not a newly launched isolated Chrome window.

Environment:

Codex App: 26.623.42026 (build 4514)
Codex CLI: codex-cli 0.142.1
Chrome: Google Chrome 149.0.7827.199
Platform: Darwin 25.5.0 arm64 arm
sw_vers: macOS 26.5.1, build 25F80

Local observations after the prompt appeared:

lsof -nP -iTCP:9222
Google    <pid> <user>  ...  TCP 127.0.0.1:9222 (LISTEN)

ps also showed the Codex app running and the bundled Chrome extension host process:

~/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/Codex for Chrome chrome-extension://...

Expected behavior:

Chrome remote debugging / external browser control should not be initialized by background or ambient Codex tasks without explicit user-visible intent and attribution. If Codex needs to attach to an existing Chrome instance, the UI should clearly show which visible Codex task requested it.