Qwen Code Cua Driver 权限简化执行解析从 consent broker 到 standard / bounded / unrestricted 三模式授权【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本篇技术指南围绕 qwen-code 仓库中 Cua Driver 的权限简化Permission Simplification执行记录展开解读该项目如何将原先依赖 Cua 自有同意弹窗consent modal/banner的授权模型收敛为标准standard、有界bounded、不受限unrestricted三模式 进程指纹 启动授权launch grant的统一授权架构。读完本文你将掌握 Cua Driver 权限模式的完整契约、各执行检查点的落地细节、可复制的 CLI/环境变量配置方式以及对应的源码实现与验证证据所在位置。一、项目背景一次权限简化要解决什么问题Cua Driverpackages/cua-driver是 qwen-code 仓库中面向桌面的浏览器/系统控制驱动通过 MCP、CLI、原始 socket 与嵌入式 SDK 暴露给 AI Agent。早期版本中已有 Chromium 配置文件的授权依赖一个 Cua 自有的同意弹窗与横幅consent modal/banner而其底层授权凭证是同用户可写的临时目录中的无签名 JSON 文件任何同用户进程都可以直接伪造——这被权限模式计划文档标记为 P0 级风险见 driver-permission-modes-and-consent-plan.md。权限简化执行日志permission-simplification-execution-journal.md记录的正是这条演进路线的收尾工作状态Active实现分支codex/permission-simplification-0130起始源码e2c52d50ba331798a3da4871fdad3bbcdd399633起始 Cua Driver 版本0.12.6其核心目标Completion bar包括实现统一的标准/有界/不受限契约为已认证的 Chromium 既有配置文件保留显式授权通道移除 Cua 自有的同意弹窗与横幅行为保留矢量语义光标并新增净化后的公共会话徽章同步更新 Rust、CLI、MCP、Python、TypeScript、安装器、示例与公开文档在 macOS、Windows、Linux X11、Linux Wayland 与 Linux headless 环境完成验证且不创建或发布组件级 release。二、三模式授权契约standard / bounded / unrestricted权限简化的核心产物是三个用户可见的授权模式。根据计划文档与源码 authorization.rs 中的PermissionMode枚举bounded是官方中间态名称autonomous保留为兼容别名yolo只是unrestricted的 CLI 别名模式预期体验安全含义standard默认高风险资源一次受保护批准之后仅在重大后果操作或范围扩展时再次询问人在定义好的边界上保持介入bounded兼容别名autonomous启动时一次受保护批准之后在声明的能力包络内无人值守运行提示被预先授权的窄技术策略取代而非由模型判断取代unrestricted显式绕过显式可信启动后无运行时批准提示用户接受提示注入与非预期操作风险内置能力上限、托管/用户策略与硬完整性控制仍然生效关键约束源码级佐证模式在 daemon 启动时一次性解析、不可由工具调用或传输参数修改见 authorization.rs 的模块注释与OnceLock缓存unrestricted必须同时提供危险确认标志standard/bounded携带该标志反而报错见parse_permission_modeauthorization.rs管理员可通过环境变量彻底禁用unrestrictedCUA_DRIVER_DISABLE_UNRESTRICTED1见 authorization.rs。2.1 授权决策等式五层求交计划的授权等式为五层交集见 driver-permission-modes-and-consent-plan.mdhard invariants AND managed capability ceiling AND user/session capability policy AND mode-specific consent/grant decision AND live resource identity proof求值规则硬不变式失败一律拒绝托管策略拒绝一律拒绝用户/会话策略拒绝一律拒绝只有策略放行后模式才决定是否还需要受保护批准或已有授权批准永远不会扩大策略只满足策略包络内的 ask 需求资源身份在每次变更前与重连后重新校验。2.2 风险分级 R0–R4按能力而非模型措辞分类所有工具与子操作被赋予静态风险元数据分类表来自 driver-permission-modes-and-consent-plan.md实现于 authorization.rs 的RiskClass等级含义示例R0公开元数据工具 schema、屏幕尺寸、驱动版本R1本地可逆控制隔离配置文件中点击/输入R2敏感观察/控制截图、剪贴板读取、用户文档、已登录浏览器R3后果性外部动作发送消息、发布、上传、下载、提交表单R4关键/不可逆凭据、支付、安全设置、账户删除Unclassified未分类是 fail-closed 哨兵任何未审查工具都不可执行——authorize_tool_call_with_context对未分类调用直接返回拒绝authorization.rs。三、执行检查点拆解从描述符到 UI 移除执行日志按六个检查点记录了落地方案以下逐一展开并结合源码说明。3.1 源码同步先合并依赖 PR #2603所有必需检查通过后再从合并后的origin/main创建实现分支确认工作树干净且包含精确上游提交无关的本地规划文件保留在原工作树中。3.2 描述符与溯源基础进程指纹取代 PID这是权限简化中最关键的安全加固包含五项落地内容行为矩阵为每个已审查的执行适配器enforcement adapter增加显式的 allow / deny / manifest / grant 行为矩阵。在 authorization.rs 中可以看到完整的ENFORCEMENT_ADAPTERS静态清单覆盖browser_prepare.isolated、browser_prepare.existing_profile、private_observation、desktop_input、file_transfer_and_output、browser_consequential_action、browser_unbounded_script、browser_bound_input、process_control、os_permission_prompt、driver_configuration、clipboard、devices、shell_and_network等适配器每个都声明了risk_class、scope_keys、TTL、refusal_code与按模式的行为。脱离 consent broker常规的标准观察、输入、文件传输、录制、浏览器输入与 agent 可调配置不再依赖遗留同意代理。无界操作仍被拒无界页面变更如page工具的execute_javascript、click_element等动作与操作系统权限提示在可信边界之外保持拒绝。进程指纹取代 PID-only 记录仅凭 PID 无法证明进程身份改为进程指纹process fingerprint标识。启动快照 派发时再验证启动时记录运行中进程快照并做事后认证只有新观察到的进程能进入运行时所有权注册表在驱动自有进程终止前派发时重新验证指纹并清除过期溯源。标准模式拒绝外部进程终止标准模式下对非驱动自有进程的终止直接拒绝且不弹出任何同意界面——这是移除 consent 弹窗与保持安全同时成立的典型设计。此阶段的验证cargo test -p cua-driver-core --lib413 项通过cargo check -p cua-driver-core --all-targets通过。3.3 有界模式与终端撤销manifest v2 与 revoke-all latch有界bounded模式的落地包括manifest v2新增 manifest 版本 2同时保持版本 1 可加载兼容升级路径新授权维度应用身份授权application identity grants、实用目录根directory roots、浏览器配置文件类型browser profile kinds、驱动自有 vs 外部进程终止规则driver-owned versus foreign termination路径根匹配改为组件感知 基于规范化路径的匹配避免字符串前缀误判认证增强在 manifest 匹配前用应用身份丰富活动窗口与进程认证既有配置文件直绑匹配的 bounded manifest 可直接绑定既有配置文件浏览器无需 consent provider 或指示器终端撤销会话结束、授权上下文被撤销、以及终端运行时 revoke-all latch 都会产生稳定的派发拒绝revoke-all 之后即使调用携带新的公共会话标签也会被拒绝防止 latch 被绕过。此阶段验证cargo check -p cua-driver-core --all-targets、cargo check -p cua-driver --all-targets通过聚焦的 bounded no-provider 与 terminal-revocation 测试通过。3.4 宿主集成、UI 移除与会话身份这是权限简化最具辨识度的一部分启动授权--grant existing-profile为mcp与serve增加可重复的--grant existing-profile启动配置支持代理转发当不兼容的 daemon 已在运行时拒绝重启。源码见 cli.rs 生成的参数定义与 authorization.rs 的configure_launch_grants——该函数明确授权只来自可信启动配置绝不从环境变量或工具参数读取。公共 SDK 回调新增DriverAuthorizationHost回调与无内容的DriverActivityObserver覆盖 Rust、Python、TypeScript 三套 SDK 表面对应 crate 见 authorization_host.rs 与 activity_observer.rs。活动事件为已授权动作、授权拒绝、普通失败、授权生命周期、会话生命周期增加活动事件。移除原生 consent UI删除原生 Cua 授权模态框、横幅、helper 模式、平台 consent 渲染器以及整个overlay-uicrate。保留浏览器/OS 自有流程浏览器自有的 Chromium 连接提示与操作系统权限流程如 macOS TCC、Windows 权限不受影响——这是刻意为之Cua 不再重复实现系统级 UI。公共会话徽章在语义光标下方新增渲染器自有的公共会话徽章使用打包的 Inter 字体素材包含净化处理、稳定会话色与实时缩放并接入 macOS、Windows、Linux X11、layer-shell 渲染与 GNOME Wayland helper API v6wayland-helper 目录承载相关实现。重新生成绑定Python 与 TypeScript 的 UniFFI 绑定重新生成。此阶段验证Core/SDK/cursor 单元套件 482 项通过cargo test -p cua-driver单元套件 136 项通过TypeScript 套件 6 项通过Python 套件 28 项通过、3 项因未暂存捆绑可执行文件而跳过。3.5 公共契约与迁移指南面向使用者的契约层更新包括以无提示的实用默认替代原先提示密集的标准模式指导新增模式矩阵、bounded manifest v2 指南、启动授权流程、SDK 宿主回调示例、活动观察者契约、撤销行为、同用户边界、会话徽章与 headless 行为说明同步更新生成的 CLI/MCP 参考、包 README、嵌入与浏览器 skills、光标创作文档、升级指南与共享的安装后提示并从公开文档中移除过时的原生 consent UI 截图。3.6 本地审查关卡交付前的本地门禁包含生成的 CLI/MCP 参考与 UniFFI 绑定保持最新完整构建公开文档站点并检查内部链接与文档卫生重建并暂存精确的本地 SDK 库后再跑包测试确保测试针对当前 ABI 而非旧二进制。验证结果为cargo test -p cua-driver通过含 136 项二进制单元测试与全部非忽略集成测试TypeScript 类型检查与包套件 6 项通过Python 套件 28 项通过、3 项可选可执行文件检查跳过文档生产构建通过93 个静态页面文档链接检查 0 错误文档卫生检查通过cargo fmt --all -- --check通过聚焦的 Clippy 检查覆盖变更的 core 与 cursor crates。四、实操CLI 与配置表面综合计划文档与 cli.rs 的用法输出三种模式的启动命令如下# 默认标准模式 cua-driver serve --permission-mode standard # 有界模式需要显式能力清单与启动批准 cua-driver serve --permission-mode bounded \ --capability-manifest /trusted/task.yaml \ --approve-capability-manifest # 不受限模式必须同时给出危险确认标志 cua-driver serve --permission-mode unrestricted --dangerously-bypass-approvals # 预授权既有 Chromium 配置文件可重复 cua-driver mcp --grant existing-profile cua-driver serve --grant existing-profile参数语义来自 cli.rs 的生成参考参数类型说明--permission-mode modestring不可变的 daemon 授权模式standard、bounded 或 unrestricted默认 standard--grant existing-profilerepeatable预授权标准模式下的既有配置文件边界重复使用合法--dangerously-bypass-approvalsflag选择 unrestricted 模式并确认其风险--capability-manifest pathstring可选、仅收窄的工具/资源上限bounded 模式必需--approve-capability-manifestflag可信启动器确认已审查该能力清单--session-policy/--approve-session-policystring/flag已弃用的--capability-manifest/--approve-capability-manifest别名4.1 环境变量契约嵌入式与程序化启动器使用双值环境变量契约见 authorization.rs 与 policy.rs# 方式一交互式 CLI 用标志等价于下方双值契约 # 方式二程序化/嵌入式启动 export CUA_DRIVER_PERMISSION_MODEunrestricted export CUA_DRIVER_DANGEROUSLY_BYPASS_APPROVALS1 # 管理员禁用 unrestricted export CUA_DRIVER_DISABLE_UNRESTRICTED1 # 用户策略与托管策略可同时配置取交集 export CUA_DRIVER_POLICY_FILE/path/to/user.yaml export CUA_DRIVER_MANAGED_POLICY_FILE/path/to/managed.yaml # 能力清单及其启动批准 export CUA_DRIVER_CAPABILITY_MANIFEST_FILE/trusted/task.yaml export CUA_DRIVER_CAPABILITY_MANIFEST_APPROVED1环境标志解析接受1/true/yes/on不区分大小写见 authorization.rs。4.2 有界模式能力清单示例有界模式的--capability-manifest是独立于 YAML/Rego 策略的新 schema编译为不可变的内存授权层与内置上限、托管/用户策略求交。结构来自 session_manifest.rs 的字段allow/deny/ask 工具集、既有配置文件、浏览器 origins、应用授权、可读写路径、可终止 PID、配置变更等version: 2 mode: bounded expires_after: 8h idle_timeout: 30m resources: applications: - bundle_id: com.google.Chrome browser: profile: Work origins: - https://docs.example.com - https://app.example.com allow: tools: - start_session - end_session - get_browser_state - browser_navigate - browser_click - browser_type - wait deny: tools: - page - shell_execute ask: tools: - browser_download - browser_set_input_files注意ask属于新的 manifest schema不是旧 YAML 策略的语法manifest 中未声明的工具默认拒绝deny-by-defaultauthorize_tool_call_with_context对Undeclared直接返回拒绝authorization.rs。Agent 可以提议manifest但不能自行批准或安装它——批准必须由可信启动器通过--approve-capability-manifest或对应环境变量完成。4.3 策略引擎YAML / Rego 双格式与 fail-closed能力上限由 policy.rs 承载支持 YAMLallow.tools/allow.rules/deny.tools与 Regodata.cua.policy.allow布尔规则两种格式显式配置的缺失路径即启动错误PolicyEngine::load对不存在的路径直接bailpolicy.rsvalidate_configured_policy在任何动作端点暴露前完成急切校验policy.rs杜绝策略路径拼写错误导致静默全放行策略加载前后双重哈希load_configured_layer在加载前后各计算一次 SHA-256若内容变化则报错policy.rs防止 TOCTOU托管与用户策略求交authorize_tool_call依次求值 managed 与 user 两层任一拒绝即拒绝policy.rs单元测试managed_and_user_layers_are_intersected证明用户层可以收窄托管层的 allowYAML 约束支持min/max/max_length/pattern/allowed五类参数约束policy.rs例如把click限制在 1920×1080 范围内、把type文本限制为小写字母且长度 ≤5。五、会话状态与状态输出status_jsonauthorization.rs输出内容无关的授权状态包括permission_mode与其来源trusted_startup_configuration或built_in_default、user_policy_*/managed_policy_*配置与哈希、内置上限标识reviewed_tool_and_risk_map_v1、风险元数据版本1、active/metadata_only/not_exposed 三类适配器清单含按模式的有效清单、authorization_host_assurance、能力清单状态版本、SHA-256、过期时间、空闲超时、allow/deny/ask 计数。session_policy_*等旧字段保留一个兼容窗口期。撤销方面cua-driver revoke --session id与--all提供可信本地操作员撤销路径有界/标准模式下的既有配置文件授权还会因会话结束、空闲/绝对过期、策略变更、进程/端点身份变化、daemon 重启与重连预算耗尽而自动失效见 authorization.rs 的EXISTING_PROFILE_REVOCATION。六、测试与验证布局权限相关测试集中在 permission_policy_startup_test.rs 与 daemon_required_test.rs覆盖策略启动 fail-closed、模式解析、daemon 必需授权等场景核心库侧另有 policy.rs 与 authorization.rs 内的单元测试验证standard是默认模式autonomous是bounded的兼容别名解析与序列化双向unrestricted缺少危险确认标志时报MissingDangerAcknowledgement危险标志不能削弱其他模式UnexpectedDangerAcknowledgementyolo仅在有危险确认时才等于unrestrictedbrowser_prepare的existing_profile分类为 R2/Activeisolated 分类为 R1/Active未知工具进入Unclassified并 fail-closed 拒绝显式 deny 优先于 allow空工具名与非法正则均在加载期失败。执行日志明确记录一个接口只有在同一提交上公共接口、独立 oracle 与代表性环境全部通过后才被标记为支持且已认证的existing_profile在标准/有界模式下始终 fail-closed——计划文档与实现日志一致声明/dev/tty键入APPROVE不是高保证收集器通用 MCPelicitation/create也不被信任为受保护批准渠道见 driver-permission-modes-implementation-journal.md。七、威胁模型边界明确保护谁、不保护谁权限简化并未宣称解决一切计划文档的威胁模型driver-permission-modes-and-consent-plan.md指出进程内策略引擎不是针对同用户任意原生代码的边界——拥有任意 shell 执行的本地 Agent 可以直接调用 OS 输入 API、读取同用户文件或启动第二个驱动。其保护承诺限定在仅能访问 daemon 协议的 Agent 上若要抵御同用户原生代码必须叠加外部边界独立 OS 用户/服务身份、沙箱、VM/容器 专用浏览器配置文件、托管设备策略或第二设备批准。unrestricted也从不声称抵御提示注入——在个人登录配置文件中它是对账户操作与数据丢失风险的显式接受而非安全模式。此外authorization.rs 的enforce_hard_invariants将针对 Cua Driver 自身授权进程的 PID 定向操作设为硬拒绝——Agent 无法通过kill_app、click、page等工具攻击驱动自身的授权/指示器 UI这是独立于模式的硬不变式。八、延伸阅读执行日志本文主体permission-simplification-execution-journal.md权限模式设计计划三模式、威胁模型、风险分级、验证方案driver-permission-modes-and-consent-plan.md前一阶段实施日志含平台认证 SHA 与发布切片driver-permission-modes-implementation-journal.md核心实现策略引擎 policy.rs、授权协调 authorization.rs、能力清单 session_manifest.rsCLI 参数定义cli.rsSDK 宿主回调与活动观察者authorization_host.rs、activity_observer.rs测试入口permission_policy_startup_test.rs、daemon_required_test.rs驱动整体说明cua-driver/README.md【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Qwen Code Cua Driver 权限简化执行解析：从 consent broker 到 standard / bounded / unrestricted 三模式授权
Qwen Code Cua Driver 权限简化执行解析从 consent broker 到 standard / bounded / unrestricted 三模式授权【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本篇技术指南围绕 qwen-code 仓库中 Cua Driver 的权限简化Permission Simplification执行记录展开解读该项目如何将原先依赖 Cua 自有同意弹窗consent modal/banner的授权模型收敛为标准standard、有界bounded、不受限unrestricted三模式 进程指纹 启动授权launch grant的统一授权架构。读完本文你将掌握 Cua Driver 权限模式的完整契约、各执行检查点的落地细节、可复制的 CLI/环境变量配置方式以及对应的源码实现与验证证据所在位置。一、项目背景一次权限简化要解决什么问题Cua Driverpackages/cua-driver是 qwen-code 仓库中面向桌面的浏览器/系统控制驱动通过 MCP、CLI、原始 socket 与嵌入式 SDK 暴露给 AI Agent。早期版本中已有 Chromium 配置文件的授权依赖一个 Cua 自有的同意弹窗与横幅consent modal/banner而其底层授权凭证是同用户可写的临时目录中的无签名 JSON 文件任何同用户进程都可以直接伪造——这被权限模式计划文档标记为 P0 级风险见 driver-permission-modes-and-consent-plan.md。权限简化执行日志permission-simplification-execution-journal.md记录的正是这条演进路线的收尾工作状态Active实现分支codex/permission-simplification-0130起始源码e2c52d50ba331798a3da4871fdad3bbcdd399633起始 Cua Driver 版本0.12.6其核心目标Completion bar包括实现统一的标准/有界/不受限契约为已认证的 Chromium 既有配置文件保留显式授权通道移除 Cua 自有的同意弹窗与横幅行为保留矢量语义光标并新增净化后的公共会话徽章同步更新 Rust、CLI、MCP、Python、TypeScript、安装器、示例与公开文档在 macOS、Windows、Linux X11、Linux Wayland 与 Linux headless 环境完成验证且不创建或发布组件级 release。二、三模式授权契约standard / bounded / unrestricted权限简化的核心产物是三个用户可见的授权模式。根据计划文档与源码 authorization.rs 中的PermissionMode枚举bounded是官方中间态名称autonomous保留为兼容别名yolo只是unrestricted的 CLI 别名模式预期体验安全含义standard默认高风险资源一次受保护批准之后仅在重大后果操作或范围扩展时再次询问人在定义好的边界上保持介入bounded兼容别名autonomous启动时一次受保护批准之后在声明的能力包络内无人值守运行提示被预先授权的窄技术策略取代而非由模型判断取代unrestricted显式绕过显式可信启动后无运行时批准提示用户接受提示注入与非预期操作风险内置能力上限、托管/用户策略与硬完整性控制仍然生效关键约束源码级佐证模式在 daemon 启动时一次性解析、不可由工具调用或传输参数修改见 authorization.rs 的模块注释与OnceLock缓存unrestricted必须同时提供危险确认标志standard/bounded携带该标志反而报错见parse_permission_modeauthorization.rs管理员可通过环境变量彻底禁用unrestrictedCUA_DRIVER_DISABLE_UNRESTRICTED1见 authorization.rs。2.1 授权决策等式五层求交计划的授权等式为五层交集见 driver-permission-modes-and-consent-plan.mdhard invariants AND managed capability ceiling AND user/session capability policy AND mode-specific consent/grant decision AND live resource identity proof求值规则硬不变式失败一律拒绝托管策略拒绝一律拒绝用户/会话策略拒绝一律拒绝只有策略放行后模式才决定是否还需要受保护批准或已有授权批准永远不会扩大策略只满足策略包络内的 ask 需求资源身份在每次变更前与重连后重新校验。2.2 风险分级 R0–R4按能力而非模型措辞分类所有工具与子操作被赋予静态风险元数据分类表来自 driver-permission-modes-and-consent-plan.md实现于 authorization.rs 的RiskClass等级含义示例R0公开元数据工具 schema、屏幕尺寸、驱动版本R1本地可逆控制隔离配置文件中点击/输入R2敏感观察/控制截图、剪贴板读取、用户文档、已登录浏览器R3后果性外部动作发送消息、发布、上传、下载、提交表单R4关键/不可逆凭据、支付、安全设置、账户删除Unclassified未分类是 fail-closed 哨兵任何未审查工具都不可执行——authorize_tool_call_with_context对未分类调用直接返回拒绝authorization.rs。三、执行检查点拆解从描述符到 UI 移除执行日志按六个检查点记录了落地方案以下逐一展开并结合源码说明。3.1 源码同步先合并依赖 PR #2603所有必需检查通过后再从合并后的origin/main创建实现分支确认工作树干净且包含精确上游提交无关的本地规划文件保留在原工作树中。3.2 描述符与溯源基础进程指纹取代 PID这是权限简化中最关键的安全加固包含五项落地内容行为矩阵为每个已审查的执行适配器enforcement adapter增加显式的 allow / deny / manifest / grant 行为矩阵。在 authorization.rs 中可以看到完整的ENFORCEMENT_ADAPTERS静态清单覆盖browser_prepare.isolated、browser_prepare.existing_profile、private_observation、desktop_input、file_transfer_and_output、browser_consequential_action、browser_unbounded_script、browser_bound_input、process_control、os_permission_prompt、driver_configuration、clipboard、devices、shell_and_network等适配器每个都声明了risk_class、scope_keys、TTL、refusal_code与按模式的行为。脱离 consent broker常规的标准观察、输入、文件传输、录制、浏览器输入与 agent 可调配置不再依赖遗留同意代理。无界操作仍被拒无界页面变更如page工具的execute_javascript、click_element等动作与操作系统权限提示在可信边界之外保持拒绝。进程指纹取代 PID-only 记录仅凭 PID 无法证明进程身份改为进程指纹process fingerprint标识。启动快照 派发时再验证启动时记录运行中进程快照并做事后认证只有新观察到的进程能进入运行时所有权注册表在驱动自有进程终止前派发时重新验证指纹并清除过期溯源。标准模式拒绝外部进程终止标准模式下对非驱动自有进程的终止直接拒绝且不弹出任何同意界面——这是移除 consent 弹窗与保持安全同时成立的典型设计。此阶段的验证cargo test -p cua-driver-core --lib413 项通过cargo check -p cua-driver-core --all-targets通过。3.3 有界模式与终端撤销manifest v2 与 revoke-all latch有界bounded模式的落地包括manifest v2新增 manifest 版本 2同时保持版本 1 可加载兼容升级路径新授权维度应用身份授权application identity grants、实用目录根directory roots、浏览器配置文件类型browser profile kinds、驱动自有 vs 外部进程终止规则driver-owned versus foreign termination路径根匹配改为组件感知 基于规范化路径的匹配避免字符串前缀误判认证增强在 manifest 匹配前用应用身份丰富活动窗口与进程认证既有配置文件直绑匹配的 bounded manifest 可直接绑定既有配置文件浏览器无需 consent provider 或指示器终端撤销会话结束、授权上下文被撤销、以及终端运行时 revoke-all latch 都会产生稳定的派发拒绝revoke-all 之后即使调用携带新的公共会话标签也会被拒绝防止 latch 被绕过。此阶段验证cargo check -p cua-driver-core --all-targets、cargo check -p cua-driver --all-targets通过聚焦的 bounded no-provider 与 terminal-revocation 测试通过。3.4 宿主集成、UI 移除与会话身份这是权限简化最具辨识度的一部分启动授权--grant existing-profile为mcp与serve增加可重复的--grant existing-profile启动配置支持代理转发当不兼容的 daemon 已在运行时拒绝重启。源码见 cli.rs 生成的参数定义与 authorization.rs 的configure_launch_grants——该函数明确授权只来自可信启动配置绝不从环境变量或工具参数读取。公共 SDK 回调新增DriverAuthorizationHost回调与无内容的DriverActivityObserver覆盖 Rust、Python、TypeScript 三套 SDK 表面对应 crate 见 authorization_host.rs 与 activity_observer.rs。活动事件为已授权动作、授权拒绝、普通失败、授权生命周期、会话生命周期增加活动事件。移除原生 consent UI删除原生 Cua 授权模态框、横幅、helper 模式、平台 consent 渲染器以及整个overlay-uicrate。保留浏览器/OS 自有流程浏览器自有的 Chromium 连接提示与操作系统权限流程如 macOS TCC、Windows 权限不受影响——这是刻意为之Cua 不再重复实现系统级 UI。公共会话徽章在语义光标下方新增渲染器自有的公共会话徽章使用打包的 Inter 字体素材包含净化处理、稳定会话色与实时缩放并接入 macOS、Windows、Linux X11、layer-shell 渲染与 GNOME Wayland helper API v6wayland-helper 目录承载相关实现。重新生成绑定Python 与 TypeScript 的 UniFFI 绑定重新生成。此阶段验证Core/SDK/cursor 单元套件 482 项通过cargo test -p cua-driver单元套件 136 项通过TypeScript 套件 6 项通过Python 套件 28 项通过、3 项因未暂存捆绑可执行文件而跳过。3.5 公共契约与迁移指南面向使用者的契约层更新包括以无提示的实用默认替代原先提示密集的标准模式指导新增模式矩阵、bounded manifest v2 指南、启动授权流程、SDK 宿主回调示例、活动观察者契约、撤销行为、同用户边界、会话徽章与 headless 行为说明同步更新生成的 CLI/MCP 参考、包 README、嵌入与浏览器 skills、光标创作文档、升级指南与共享的安装后提示并从公开文档中移除过时的原生 consent UI 截图。3.6 本地审查关卡交付前的本地门禁包含生成的 CLI/MCP 参考与 UniFFI 绑定保持最新完整构建公开文档站点并检查内部链接与文档卫生重建并暂存精确的本地 SDK 库后再跑包测试确保测试针对当前 ABI 而非旧二进制。验证结果为cargo test -p cua-driver通过含 136 项二进制单元测试与全部非忽略集成测试TypeScript 类型检查与包套件 6 项通过Python 套件 28 项通过、3 项可选可执行文件检查跳过文档生产构建通过93 个静态页面文档链接检查 0 错误文档卫生检查通过cargo fmt --all -- --check通过聚焦的 Clippy 检查覆盖变更的 core 与 cursor crates。四、实操CLI 与配置表面综合计划文档与 cli.rs 的用法输出三种模式的启动命令如下# 默认标准模式 cua-driver serve --permission-mode standard # 有界模式需要显式能力清单与启动批准 cua-driver serve --permission-mode bounded \ --capability-manifest /trusted/task.yaml \ --approve-capability-manifest # 不受限模式必须同时给出危险确认标志 cua-driver serve --permission-mode unrestricted --dangerously-bypass-approvals # 预授权既有 Chromium 配置文件可重复 cua-driver mcp --grant existing-profile cua-driver serve --grant existing-profile参数语义来自 cli.rs 的生成参考参数类型说明--permission-mode modestring不可变的 daemon 授权模式standard、bounded 或 unrestricted默认 standard--grant existing-profilerepeatable预授权标准模式下的既有配置文件边界重复使用合法--dangerously-bypass-approvalsflag选择 unrestricted 模式并确认其风险--capability-manifest pathstring可选、仅收窄的工具/资源上限bounded 模式必需--approve-capability-manifestflag可信启动器确认已审查该能力清单--session-policy/--approve-session-policystring/flag已弃用的--capability-manifest/--approve-capability-manifest别名4.1 环境变量契约嵌入式与程序化启动器使用双值环境变量契约见 authorization.rs 与 policy.rs# 方式一交互式 CLI 用标志等价于下方双值契约 # 方式二程序化/嵌入式启动 export CUA_DRIVER_PERMISSION_MODEunrestricted export CUA_DRIVER_DANGEROUSLY_BYPASS_APPROVALS1 # 管理员禁用 unrestricted export CUA_DRIVER_DISABLE_UNRESTRICTED1 # 用户策略与托管策略可同时配置取交集 export CUA_DRIVER_POLICY_FILE/path/to/user.yaml export CUA_DRIVER_MANAGED_POLICY_FILE/path/to/managed.yaml # 能力清单及其启动批准 export CUA_DRIVER_CAPABILITY_MANIFEST_FILE/trusted/task.yaml export CUA_DRIVER_CAPABILITY_MANIFEST_APPROVED1环境标志解析接受1/true/yes/on不区分大小写见 authorization.rs。4.2 有界模式能力清单示例有界模式的--capability-manifest是独立于 YAML/Rego 策略的新 schema编译为不可变的内存授权层与内置上限、托管/用户策略求交。结构来自 session_manifest.rs 的字段allow/deny/ask 工具集、既有配置文件、浏览器 origins、应用授权、可读写路径、可终止 PID、配置变更等version: 2 mode: bounded expires_after: 8h idle_timeout: 30m resources: applications: - bundle_id: com.google.Chrome browser: profile: Work origins: - https://docs.example.com - https://app.example.com allow: tools: - start_session - end_session - get_browser_state - browser_navigate - browser_click - browser_type - wait deny: tools: - page - shell_execute ask: tools: - browser_download - browser_set_input_files注意ask属于新的 manifest schema不是旧 YAML 策略的语法manifest 中未声明的工具默认拒绝deny-by-defaultauthorize_tool_call_with_context对Undeclared直接返回拒绝authorization.rs。Agent 可以提议manifest但不能自行批准或安装它——批准必须由可信启动器通过--approve-capability-manifest或对应环境变量完成。4.3 策略引擎YAML / Rego 双格式与 fail-closed能力上限由 policy.rs 承载支持 YAMLallow.tools/allow.rules/deny.tools与 Regodata.cua.policy.allow布尔规则两种格式显式配置的缺失路径即启动错误PolicyEngine::load对不存在的路径直接bailpolicy.rsvalidate_configured_policy在任何动作端点暴露前完成急切校验policy.rs杜绝策略路径拼写错误导致静默全放行策略加载前后双重哈希load_configured_layer在加载前后各计算一次 SHA-256若内容变化则报错policy.rs防止 TOCTOU托管与用户策略求交authorize_tool_call依次求值 managed 与 user 两层任一拒绝即拒绝policy.rs单元测试managed_and_user_layers_are_intersected证明用户层可以收窄托管层的 allowYAML 约束支持min/max/max_length/pattern/allowed五类参数约束policy.rs例如把click限制在 1920×1080 范围内、把type文本限制为小写字母且长度 ≤5。五、会话状态与状态输出status_jsonauthorization.rs输出内容无关的授权状态包括permission_mode与其来源trusted_startup_configuration或built_in_default、user_policy_*/managed_policy_*配置与哈希、内置上限标识reviewed_tool_and_risk_map_v1、风险元数据版本1、active/metadata_only/not_exposed 三类适配器清单含按模式的有效清单、authorization_host_assurance、能力清单状态版本、SHA-256、过期时间、空闲超时、allow/deny/ask 计数。session_policy_*等旧字段保留一个兼容窗口期。撤销方面cua-driver revoke --session id与--all提供可信本地操作员撤销路径有界/标准模式下的既有配置文件授权还会因会话结束、空闲/绝对过期、策略变更、进程/端点身份变化、daemon 重启与重连预算耗尽而自动失效见 authorization.rs 的EXISTING_PROFILE_REVOCATION。六、测试与验证布局权限相关测试集中在 permission_policy_startup_test.rs 与 daemon_required_test.rs覆盖策略启动 fail-closed、模式解析、daemon 必需授权等场景核心库侧另有 policy.rs 与 authorization.rs 内的单元测试验证standard是默认模式autonomous是bounded的兼容别名解析与序列化双向unrestricted缺少危险确认标志时报MissingDangerAcknowledgement危险标志不能削弱其他模式UnexpectedDangerAcknowledgementyolo仅在有危险确认时才等于unrestrictedbrowser_prepare的existing_profile分类为 R2/Activeisolated 分类为 R1/Active未知工具进入Unclassified并 fail-closed 拒绝显式 deny 优先于 allow空工具名与非法正则均在加载期失败。执行日志明确记录一个接口只有在同一提交上公共接口、独立 oracle 与代表性环境全部通过后才被标记为支持且已认证的existing_profile在标准/有界模式下始终 fail-closed——计划文档与实现日志一致声明/dev/tty键入APPROVE不是高保证收集器通用 MCPelicitation/create也不被信任为受保护批准渠道见 driver-permission-modes-implementation-journal.md。七、威胁模型边界明确保护谁、不保护谁权限简化并未宣称解决一切计划文档的威胁模型driver-permission-modes-and-consent-plan.md指出进程内策略引擎不是针对同用户任意原生代码的边界——拥有任意 shell 执行的本地 Agent 可以直接调用 OS 输入 API、读取同用户文件或启动第二个驱动。其保护承诺限定在仅能访问 daemon 协议的 Agent 上若要抵御同用户原生代码必须叠加外部边界独立 OS 用户/服务身份、沙箱、VM/容器 专用浏览器配置文件、托管设备策略或第二设备批准。unrestricted也从不声称抵御提示注入——在个人登录配置文件中它是对账户操作与数据丢失风险的显式接受而非安全模式。此外authorization.rs 的enforce_hard_invariants将针对 Cua Driver 自身授权进程的 PID 定向操作设为硬拒绝——Agent 无法通过kill_app、click、page等工具攻击驱动自身的授权/指示器 UI这是独立于模式的硬不变式。八、延伸阅读执行日志本文主体permission-simplification-execution-journal.md权限模式设计计划三模式、威胁模型、风险分级、验证方案driver-permission-modes-and-consent-plan.md前一阶段实施日志含平台认证 SHA 与发布切片driver-permission-modes-implementation-journal.md核心实现策略引擎 policy.rs、授权协调 authorization.rs、能力清单 session_manifest.rsCLI 参数定义cli.rsSDK 宿主回调与活动观察者authorization_host.rs、activity_observer.rs测试入口permission_policy_startup_test.rs、daemon_required_test.rs驱动整体说明cua-driver/README.md【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考