[Bug] CDP mode: Browser closes immediately after command finishes even with OPENCLI_CDP_ONLY=true

[feehoo]

Describe the bug
When using remote CDP mode, the Chrome browser on the remote machine (192.168.248.222) closes immediately as soon as any opencli command finishes, even though:

OPENCLI_CDP_ENDPOINT is correctly set to a remote Chrome instance
OPENCLI_CDP_ONLY=true is explicitly set
opencli doctor shows [OK] CDP endpoint and "Remote Chrome mode: extension token not required"
Chrome is started with proper flags: --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --remote-allow-origins="*"

This happens on both v0.9.8 (before and after npm install -g @jackwener/opencli@latest).
To Reproduce

On remote machine (192.168.248.222):Bashnohup google-chrome
--remote-debugging-port=9222
--remote-debugging-address=0.0.0.0
--user-data-dir="$HOME/chrome-debug-profile-opencli"
--remote-allow-origins="*"
--no-first-run
--disable-background-mode > /dev/null 2>&1 &
On client machine:Bashexport OPENCLI_CDP_ENDPOINT="http://192.168.248.222:9222"
export OPENCLI_CDP_ONLY="true"
opencli doctor # → shows OK
opencli zhihu search --keyword "test" # command runs, but browser closes right after

Expected behavior
In pure CDP/remote mode, OpenCLI should only connect to the existing Chrome instance and never close or kill it after the command finishes. The browser should remain open until the user manually closes it.
Actual behavior
Browser process disappears immediately after the command exits.
Environment

opencli version: 0.9.8 (latest as of Mar 19, 2026)
Chrome: latest stable (started with CDP flags)
OS (remote): Linux (Ubuntu/Debian on 2080ti)
OS (client): macOS / Linux (using export)
Connection: direct IP (no SSH tunnel in this test)

Additional context

CDP support was added very recently (19 hours ago).
This makes remote/headless usage almost unusable, because the whole point of CDP is to keep a persistent Chrome session with login cookies.
Workaround tried: nohup, tmux, separate --user-data-dir, but still closes.

Would be great if we can add an environment variable like OPENCLI_KEEP_BROWSER_OPEN=true or make CDP mode truly non-destructive by default.
Thanks!

[xuelin25]

同样在 macOS (Apple Silicon) + Chrome 146 + opencli v0.9.8 上遇到了 CDP 相关问题，补充一下本地场景的完整 workaround 和额外发现。

背景

Chrome 146 新增了安全限制：--remote-debugging-port 必须搭配独立 --user-data-dir，默认 profile 下该参数会被静默忽略。所以 CDP 模式下必须用一个独立的 Chrome 实例。

macOS 本地 CDP Workaround

1. 启动独立 Debug Chrome

# macOS 上 open -a 无法传递 --remote-debugging-port（会被忽略）
# 必须直接启动二进制，指定独立 user-data-dir
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile" \
  --no-first-run &

主 Chrome 和 Debug Chrome 可以同时运行（不同 --user-data-dir）。

如果需要登录态，可以从主 profile 拷贝 Cookies：

cp ~/Library/Application\ Support/Google/Chrome/Default/Cookies \
   ~/chrome-debug-profile/Default/Cookies

2. 环境变量

export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"

额外发现的问题（需要手动补丁 discover.js / mcp.js）

1. CDP 无法显式禁用：当不想用 CDP 时，没有官方方式关闭自动发现。建议支持 OPENCLI_CDP_ENDPOINT=false 或 0/off 来禁用。

2. CDP 超时太短：Playwright MCP CLI 默认超时对复杂页面不够用，建议暴露 --cdp-timeout 参数或 OPENCLI_CDP_TIMEOUT 环境变量。

3. 代理环境下 WebSocket 被拦截：如果系统配了 HTTP 代理（如 ClashX），CDP localhost 的 WebSocket 连接会被代理拦截导致失败。建议 CDP 模式下自动注入 no_proxy=localhost,127.0.0.1,[::1]。

这三个点我分别补丁了 discover.js（前两个）和 mcp.js（第三个），每次 opencli 升级后需要重新应用。如果有需要可以后续单独开 issue 或提 PR。

[jackwener]

Resolved in v1.0.0: migrated from Playwright to daemon + Chrome Extension. close() no longer kills browser. Old CDP env vars are no longer needed. Please update to latest.