feat(desktop): allow explicit OpenAI-native Computer Use and Chrome on Windows
- Dominant language
- TypeScript
- Stars
- 2.7k
- Forks
- 401
- Avg merge
- 21h 48m
- Merged PRs (30d)
- 776
Description
# feat(desktop): 支持 Windows 用户显式选择 OpenAI 原生 Computer Use 与 Chrome
本提案经需求方授权提交;行为核对日期为2026-09-08,尚未完成安装版接入。
## 使用场景
用户希望在 Cindy 对话中使用已安装的 OpenAI 官方 Codex Computer Use 和 Chrome 能力,包括用户当前浏览器状态;不希望以 Cindy 自有驱动、自制桌面 MCP 或第三方控制器替代。与此同时,需要保留逐应用/站点授权、拒绝与停止,并继续正常获取 Cindy 官方更新。
## 当前限制
本地检查基线为5ce08796,在线复核main为b2465d28;在线读取的codex-browser-companion.ts仍在平台非darwin时返回platform_unsupported。所查宿主还通过capability-routing禁用官方Computer Use Skill,并由宿主供应及会话就绪状态决定Chrome可用性。仅安装官方插件或修改用户enabled配置不能补齐宿主支持。
相关项:#1693解释了屏蔽重复Sky能力的既有实现;#2021是Cindy Computer Use/CuaDriver迁移为Cindy官方插件的议题。本提案明确要求OpenAI原生运行时,不能把#2021视为同范围替代交付。
## 已验证的可行性与边界
- Windows Store官方Codex运行时完成身份、架构和文件内容校验后,官方沙箱中固定算术执行成功。
- 使用官方库连接已核验服务端归属和签名的官方应用原生管道,应用枚举成功。
- 官方Chrome检查脚本报告浏览器运行中、扩展启用、native host注册正确。
- 创建真实临时线程后直接调用浏览器工具仍缺活动回合元数据,浏览器交互尚未验收。
- 授权/停止的本地源码回归不等于真实桌面输入停止证据。
- 当前没有通过Cindy安装版完成桌面截图、点击、Unicode输入或浏览器读写的端到端验收。没有修改安装包或绕过安全机制。
这里只提供行为结论,不附用户配置、登录信息、管道端点、窗口内容或本机路径。
## 希望维护者确认
1. 是否接受Windows下可显式选择OpenAI原生能力的正式支持方向,而不是强制替换为Cindy自有实现?
2. 选择方式采用自动识别还是用户显式设置?如何保持未选择用户的原有行为?
3. 是否已有受支持的OpenAI宿主集成契约,包含活动回合、应用/站点授权、停止、断连和更新时重新验证?本机实验不能证明接口长期兼容承诺。
4. 若方向接受,建议的PR拆分、review负责人和发布验收要求是什么?不要求维护者预先承诺发布日期。
## 建议实施范围
先加入不启用控制的官方组件发现和诊断,再加入按平台、实际能力、用户选择及授权状态裁决的宿主供应路径。桌面和浏览器就绪状态需要独立表达,不能因为Chrome暂时断开而误报所有原生能力不可用。
只使用官方运行时和官方API,禁止平台伪装、工具改名绕过限制、安装包热补丁、复制凭据、自制控制协议或关闭沙箱。更新后重新验证组件身份与依赖,不在用户配置中固化某个部署版本路径。
原生应用/站点授权必须由用户决定;默认权限宽松或自动审查不等于用户对新应用的同意。拒绝、停止、关闭和断连不能留下可继续输入的回合。不得伪造session/turn或批准元数据。
## 完整验收
- 通过正常Cindy发布产物安装或升级,未改写安装包且保留更新通道。
- 用户在Cindy内选择原生能力;官方组件缺失或未授权时给出可操作原因。
- 专用无敏感测试应用完成截图、点击、Unicode输入、遮挡窗口观察;不影响其他应用。
- Chrome专用测试页完成读取和一次可回滚交互,不改变无关页签。
- 拒绝应用/站点授权后不执行;宿主停止、Escape、断连后同回合不再输入。
- Cindy与OpenAI组件分别更新后重复验收,失败时清晰降级且不静默替换能力来源。
## 提交边界
本提案先请求架构和兼容性讨论,不宣称实现完成。代码PR需按贡献指南取得有效DCO签署、通过review和CI;不能替用户签署贡献声明,也不能用本地源码测试替代官方合入、发布和安装版验收。
Contributor guide
Research direction
Start by reading codex-browser-companion.ts and the capability-routing path referenced in the issue, then trace how host and session readiness determine Chrome and Computer Use availability on Windows. Confirm the supported integration contract before implementation. Done requires an installed Cindy build to discover and explicitly select the official components, preserve authorization and stop behavior, and pass the listed desktop and Chrome end-to-end checks without bypasses.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, typescript
- Domain
- desktop, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100