[RFC] Browser control: choosing tabs, staying out of the way, and cleaning up

I want OpenCLI to work comfortably alongside someone using Chrome. Right now, choosing an existing page depends on focus, automation can open another window, and finishing a session can leave a blank page behind. These problems already have several issues. Before adding more fixes, I think it is worth agreeing on the intended experience.

I see OpenCLI as the browser runtime for an agent, whether the steps come from a fixed adapter or the agent figures them out as it goes. The agent should decide what to do and when it is done. OpenCLI should handle targeting, waiting, and cleanup.

## Tabs and windows

The agent should be able to list existing tabs in a selected connected profile, then bind to the intended tab by identity. Listing should not change focus or ownership. If that tab disappears, fail rather than pick another one.

This builds on the existing session and page-identity support. In the inspected [`8271afc6` baseline](https://github.com/jackwener/OpenCLI/tree/8271afc67e8504bda94c147f446ee29775d08274), bind selects from the last-focused window and tab listing is session-scoped. Containers can be reused, so it would be inaccurate to say every command creates a window.

For new pages, I prefer background tabs in a selected existing window, with a separate window as an option. I do not want automation changing my desktop layout just to read a page.

I understand this differs from the owned-container default defended in [#2316](https://github.com/jackwener/OpenCLI/pull/2316#issuecomment-5462670673). Separate windows make ownership easier to manage, especially for large jobs. Using an existing window requires tracking ownership per tab: creating one tab cannot give OpenCLI ownership of the whole window. The selected window also should not follow later focus changes.

That default is the main product question I would like to discuss.

## Pausing and finishing

Ordinary operations should not steal focus. If a login, CAPTCHA, or other step needs the user, OpenCLI should return the reason and page identity. The agent can explain it in chat and wait for “continue,” then check the page before resuming. I do not think the extension needs its own takeover/resume buttons.

I would use these lifecycle rules:

- Keep the task's pages across commands. A CLI process exiting is not task completion.
- Let the agent explicitly mark a task as waiting for the user. Preserve its pages, stop automated writes, and do not apply ordinary idle cleanup.
- When the agent explicitly finishes, close its temporary tabs by default. Keep pages the agent designates as deliverables.
- Leave existing user tabs and other tasks alone. Close a whole window only if it belongs to the task and nothing in it needs to remain.

Recovery needs to distinguish abandoned work from a deliberate wait. The exact commands and timeout values can come later.

Approval should use the host harness's existing flow, without a second OpenCLI confirmation. This still requires runtime authentication, target isolation, and ownership checks.

## Test JS orchestration before choosing it

I also want to test whether JS composition reduces tokens and completion time compared with current CLI usage. Use the same OpenCLI runtime, allow reasonable shell chaining in the baseline, and repeat fixed, exploratory, and recovery tasks with the same model and starting conditions.

Count failed attempts and recovery costs. Faster runs only help if correctness and success rate hold up; report time spent waiting for a person separately.

[Ego Lite's JS workflow](https://github.com/citrolabs/ego-lite/blob/main/skills/ego-browser/SKILL.md) is a useful reference, not evidence that JS alone explains its performance. Playwright can also be scripted in JS. The question is how much work the agent can compose in one invocation. Reuse OpenCLI's existing Page and adapter support, then use the results to decide whether JS should become the preferred interface. I would not remove CLI commands before that.

## Earlier discussions

- Cleanup: [#2202](https://github.com/jackwener/OpenCLI/issues/2202), its duplicate [#2312](https://github.com/jackwener/OpenCLI/issues/2312), and PRs [#2161](https://github.com/jackwener/OpenCLI/pull/2161), [#2294](https://github.com/jackwener/OpenCLI/pull/2294).
- Grouping and focus: [#2069](https://github.com/jackwener/OpenCLI/issues/2069), [#2169](https://github.com/jackwener/OpenCLI/pull/2169), [#739](https://github.com/jackwener/OpenCLI/issues/739), [#2167](https://github.com/jackwener/OpenCLI/issues/2167). Earlier grouping work: [#1791](https://github.com/jackwener/OpenCLI/issues/1791), [#2098](https://github.com/jackwener/OpenCLI/pull/2098).
- Existing-window placement: [#1827](https://github.com/jackwener/OpenCLI/pull/1827) proposes an opt-in mode. [#984](https://github.com/jackwener/OpenCLI/pull/984) explains the objection to implicit user-window side effects.
- Sessions, binding, and keeping pages for human input: [#1427](https://github.com/jackwener/OpenCLI/issues/1427), [#1169](https://github.com/jackwener/OpenCLI/issues/1169), [#1043](https://github.com/jackwener/OpenCLI/issues/1043), [#1534](https://github.com/jackwener/OpenCLI/issues/1534), [#1542](https://github.com/jackwener/OpenCLI/pull/1542).
- Observability and targeting: [#2054](https://github.com/jackwener/OpenCLI/issues/2054), [#2364](https://github.com/jackwener/OpenCLI/issues/2364), [#2096](https://github.com/jackwener/OpenCLI/issues/2096). [#2478](https://github.com/jackwener/OpenCLI/pull/2478) clarifies lease-scoped listing but does not add global discovery.
- [#2316](https://github.com/jackwener/OpenCLI/pull/2316) was closed as a mixed PR; the maintainer invited separate batch and observability changes. [#1595](https://github.com/jackwener/OpenCLI/issues/1595) raises runtime policy questions that need reconciling with harness-native approval. [#2236](https://github.com/jackwener/OpenCLI/issues/2236) rejected a credential proxy; this proposal keeps page-bound authenticated fetch.

I would like to settle the window default and lifecycle expectations here, then make focused changes through the relevant issues. Existing bug fixes do not need to wait for this discussion.

中文版

我希望 OpenCLI 能和正在使用 Chrome 的人一起工作。目前选择已有页面还依赖焦点，自动化可能另外打开窗口，结束 session 后也可能留下空白页。相关 issue 已经不少了，我想先把期望的体验聊清楚，再继续改。

我把 OpenCLI 看作 agent 的浏览器 Runtime。步骤可以来自固定 adapter，也可以由 agent 边看边决定。Agent 决定做什么、什么时候结束，OpenCLI 负责选页、等待和清理。

### 标签与窗口

Agent 应该能列出选定、已连接 profile 中的已有标签，再按身份绑定目标。列举不改变焦点和所有权，目标消失就报错，不另找一个用户标签顶上。

现有代码已经有 session 和 page identity。核查的 `8271afc6` 中，bind 从最后聚焦的窗口选页，标签列表受 session 范围限制。容器可以复用，不能说每条命令都新建窗口。

需要新页面时，我倾向默认在选定的现有窗口开后台标签，独立窗口作为选项。我不希望只是让 agent 读个页面，就改变桌面布局。

这与 #2316 中维护者坚持的默认边界有分歧。独立窗口更容易管理归属，尤其适合大量后台任务；使用现有窗口则必须按标签管理所有权，不能因为创建一个标签就认领整个窗口，也不能跟着后来的焦点变化换窗口。我希望重点讨论这个默认值。

### 等待与结束

普通操作不抢焦点。遇到登录、验证码或必须由用户处理的步骤，OpenCLI 返回原因和页面身份，agent 在聊天里说明并等待“继续”，之后检查页面再恢复。插件不需要另做接管、继续按钮。

我建议：

- 跨命令保留任务页面，CLI 进程退出不等于任务完成。
- Agent 显式声明等待用户后，保留页面、停止自动写入，不受普通空闲清理影响。
- Agent 显式结束后，默认关闭临时标签，保留它指定的交付页面。
- 不关闭用户原有标签，不影响其他任务。只有窗口也属于任务且没有需要保留的内容时，才关闭整个窗口。

异常恢复需要区分任务遗留和有意等待，具体命令、超时时长可以后定。

审批走宿主 Harness 已有的流程，不增加第二次 OpenCLI 确认。Runtime 的连接鉴权、目标隔离和归属检查仍要保留。

### 先实验，再决定 JS 编排

我想实际比较 JS 编排能否减少 token、缩短完成时间。使用同一 OpenCLI Runtime，CLI 基线允许合理串联；相同模型和初始条件下，重复测试固定流程、探索流程和失败恢复。

失败和恢复成本也要计入，正确性、成功率不能下降，人工等待时间单独报告。Ego Lite 可作参考，但不能把它的整体性能归因于 JS。Playwright 也能用 JS 编排，实验要比较的是一次调用能组织多少工作。

先复用现有 Page 和 adapter 做实验，再决定 JS 是否成为首选入口，不预先删除 CLI。

上面的关联记录包含已有修复和未决讨论。清理继续沿 #2202 等问题推进；#1827 已提出可选的同窗口方式；#2478 仅澄清标签列表范围；#2316 允许单独讨论 batch 和可观测性，但拒绝混合改动和默认借用用户窗口；#1595 需要协调权限职责；本提案不重提 #2236 已拒绝的凭证代理。

我希望在这里先明确窗口默认值和生命周期，再沿相关 issue 做聚焦改动。独立 bug 修复不必等这次讨论结束。

Start by reviewing the existing session, page-identity, Page, and adapter support mentioned in the issue, then read the linked discussions around window ownership, cleanup, and approval. This RFC is done when the window default and lifecycle expectations are agreed; implementation should proceed through focused follow-up issues, with the JS orchestration comparison reported separately.

Written by the indexing model from the issue text.