Cua Driver × Hyprland 后台输入安全验证：桌面状态故障下的 750ms 取消与前台隔离证明

Cua Driver × Hyprland 后台输入安全验证桌面状态故障下的 750ms 取消与前台隔离证明【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua本篇技术指南围绕 Cua 仓库中 Hyprland 插件的桌面状态安全验证Desktop-state safety validation实验展开讲解如何在一次性 Omarchy Cua Fleet 虚拟机里用「故障注入 控制/动作对照」方法证明当目标窗口被移动、缩放、会话锁屏、DPMS 熄屏或销毁时正在进行的 Driver MCP 后台拖拽会立即被取消、授权被回收、输入状态被清空且不产生任何多余的前台副作用。读完本文你将掌握这套实验的完整方法学、精确产物清单、五类故障的实现方式、750ms 取消判据、几何回归修复方案以及哪些结论仍停留在实验门槛之内。实验背景与结论边界本验证记录desktop-state-validation.md是 2026-09-05 在一次性 Omarchy Cua Fleet 虚拟机中完成的一轮聚焦实验五个「仅故障对照」fault-only control与五个「Driver MCP 后台拖拽动作」action全部通过。移动、缩放、锁屏、熄屏或销毁目标窗口都会在750 ms 测试界限内取消后台动作Agent 的输入状态与授权被清空旧授权被拒绝新签发的授权可顺利完成恢复recovery。需要特别强调结论边界该记录是 draft PR #3572 的聚焦证据不是受支持的发行版也不是生产环境认证。插件的常规构建仍是仅发现discovery-only模式应用目标发现与输入变更默认未启用见 tests/README.md。此前的真实应用验证与按住输入生命周期验证各自保留自己的源码身份本轮通过不代表对它们进行重新认证。一个容易被误解的细节也值得先说明每个动作相比其对照没有产生额外的前台效果但这并不等于每种故障都会让前台保持原样——真实的会话锁屏本身就会释放前台抓取grab并改变焦点。动作与对照的测量效果一致才是本轮验证的真实含义。精确产物与环境身份全部十个最终片段五对照 五动作使用了相同的原生二进制与最终可执行测试辅助程序。原生源码 SHA 之后的改动仅局限于测试与文档因此本轮报告的提交仅改动文档。组件被测身份原生 Driver 与插件源码fc225fef9bbaa07c9953e1d80cf6fd82d66bd4fd最终可执行测试辅助源码9b1c71c67145173d902c6638805afb355b8eb305Omarchy4.0.1-1一次性 KVM Fleet 虚拟机Hyprland0.56.2-1commitefb50993780079460b0cbed1363e2166a2de1d9fPortalxdg-desktop-portal-hyprland 1.4.1-1Driver 源码与安装版本0.23.2任务本地源码构建非stock 发行版插件0.1.0显式启用的输入实验工具链GCC16.1.1、CMake4.4.3、Rust1.97.1显示单个 1920 × 1080 输出缩放 1对应的 SHA-256 产物摘要如下可用于逐字节核对原生源码归档7b7643136e80e67422fa7f37104aeed15c022529b2fd9d24ba86c4f073ffc3b4Driver57b1de8296cc41e6e8121b181056bcb1c1f20cc9d531becbf0f3221c96992b1b插件7e105e0701fe0d1104f7389e654dff59c7d7503e4e380ced1638e8295ed20358主指针夹具primary-pointer fixture32e52f55ac1be4261ba32b9328264c04e28a2f8da464f4d1f1c4a50550751cdf会话锁夹具237b694749137a518f47eb73691719d2c183ebc7649a16935e071b6aba11b856最终测试辅助归档d63a18294b40194cab5b7255eb51386a9636583666156d70f046d38d394750e1保留证据归档9e40e9136310b77798c23d91de628a196fedf15d72405f24391616cade2c44be安装的 Driver 与两个正在运行的服务可执行文件摘要一致一个服务执行动作另一个由同一二进制派生的独立服务负责录像与状态观察动作服务关闭了录制。之所以要分开两个服务是因为同一个服务的多个 MCP 连接无法隔离同步录制开销对取消时延的影响。实验保留了普通 Driver 安装未进行任何宿主机安装或 Fleet 镜像发布。几何回归把拖拽钉死在派发时接受的几何版本此前版本的拖拽检查对照的是可变的缓存目标几何。问题在于在定时器比较版本之前一次插入的目标请求或授权刷新就可能更新该缓存从而掩盖拖拽进行中的窗口移动。本轮实验把每个拖拽钉死pin在它开始时接受的几何版本上。源码层面DragGeometrysrc/drag_geometry.hpp在构造时记下被接受的版本号accepted_matches(current)仅当current accepted_时返回真——其他请求可以刷新客户端的缓存版本但不能为飞行中的拖拽重新设定基准。对应的回归测试 drag_geometry_test.cpp 模拟了以下场景在request()/approve()的忙碌拒绝发生前被消费的一次 resize缓存刷新后版本变化但定时器刷新不再看到新变化拖拽必须失败移回旧坐标也不能复活旧坐标或旧授权新建授权的拖拽只有在匹配新版本时才能通过。关键要求是这些断言在定义了NDEBUG的 Release 构建中仍然生效desktop_state_live.py在__main__里也显式要求__debug__开启drag_geometry_test.cpp用std::abort()而非assert来保证失败不被编译期优化掉。方法学控制/动作配对与前台对照desktop_state_live.py通过真实 Driver MCP 的drag与press_key调用驱动原生 GTK 裸事件raw-event夹具。Fleet SDK 只提供 VM 传输与搭建不参与后台输入路径。一个独立的虚拟主指针在前台夹具中持有真实的 Wayland 抓取见 primary_grab.c它通过zwlr_virtual_pointer_manager_v1创建虚拟指针并维持按下的主按钮HELD行输出即抓取就绪信号——它不是物理鼠标输入。每个控制/动作配对都绑定相同的故障、前台身份与几何、原生源码、模块与 Driver 摘要、对抗程序adversary二进制、测试辅助字节以及观察服务的排布。后台目标通过全新的 Driver 快照验证。操作员在访客机之外签署短生命周期的、绑定目标/连接/epoch 的测试授权grant。动作片段会等待应用真正收到按钮按下之后才向一个两秒拖拽注入故障。类型化拒绝typed refusal与观察到的清空状态必须在故障派发后750 ms 内到达——由于拖拽持续两秒自然完成不可能通过该判据。清空状态指无 lease、无活动拖拽、无按住的按钮或按键、无 Agent 指针/键盘焦点对应 desktop_state_evidence.py 中agent_cleared对lease_active、drag_active、pointer_focus、keyboard_focus、held_button、held_keys的逐项断言。存活的surviving目标还必须记录一次匹配的按钮释放意外按键或滚动事件会使拖拽片段失败。前台对照比较使用前台应用增量、Wayland 线上事件、合成器输入/焦点追踪、有序光标路径以及精确的活动窗口、工作区与光标回读。仅匹配光标终点不足以通过。对于锁屏对照记录的是合成器自身的释放与焦点变化动作不得在这些之外增加任何效果。primary_effectdesktop_state_evidence.py汇总应用增量、线上输入、线上焦点、合成器输入、合成器焦点、最大光标位移与有序光标路径compare_control则逐字段要求动作片段与对照完全相等光标位移容差 0.01 px。销毁场景要求独立观察到目标消失。两条实验通道lane的 seat、pointer、keyboard 资源计数必须回到启动目标前测得的基线destroyed_resources_pruned断言销毁后final baseline已销毁的表面无法确认释放因此该案例不主张应用收到了释放。恢复recovery使用新的进程身份即使 Hyprland 复用了旧窗口地址。每个动作片段都拒绝旧授权、拒绝未经批准unapproved的恢复输入、要求一个全新的授权然后恰好投递一次 Escape 按下/释放对recovery_input断言恢复键对恰为一次 Escape 按下 一次释放且无任何指针/滚动输入。恢复检查还要求前台应用与合成器状态不变、无前台线上输入泄漏。完整的搭建与 watchdog 要求见 tests/README.md 的桌面状态故障控制一节。五类桌面状态故障的实现细节故障由 desktop_faults.py 中的FaultController注入。它在构造时强制校验必须是显式一次性 Linux 访客--disposable且systemd-detect-virt --vm命中、所选合成器实例与测试会话一致、目标必须是仓库内tests/fixtures/apps/linux/isolated-input的精确 Background 夹具拒绝任意进程、标题匹配与用户提供的可执行命令。五类故障如下Move移动要求目标已浮动floating且非全屏通过hyprctl dispatch发出movewindowpixel exact X Y,address:addr并等待快照中at键等于新值。Resize缩放同样要求已浮动目标发出resizewindowpixel等待size键更新缩放目标尺寸必须为正且显式改变。Lock真实会话锁运行 session_lock_fixture.c 编译出的session_lock_fixture二进制用ext-session-lock-v1协议实现真实锁屏为每个通告的输出提供不透明黑色共享内存表面并等待真实的协议 lock/unlock 确认。没有表面时 Hyprland 的「缺面宽限missing-surface grace period」会推迟确认——早期尝试正是因此超时的。恢复通过unlock_and_destroywl_display.sync确认完成绝不能杀掉锁客户端来解锁崩溃的锁客户端可能让会话永久锁死此时应丢弃一次性访客。DPMS off熄屏要求所有既有监视器先确认开启派发hl.dsp.dpms({ action disable })并等待所有监视器dpmsStatus变为 false。Destroy销毁对目标夹具 PID 发送 SIGTERM通过pidfd_send_signal等待进程退出且快照中目标消失。每类故障在派发前都会武装一个独立 watchdog 子进程_watchdog锁屏场景到期后通过 SIGUSR1 请求协议解锁DPMS 场景自动派发enable并轮询恢复即使控制器崩溃watchdog 也能在 EOF 后自愈。故障证据目录拒绝覆盖既有片段回滚rollback负责把移动/缩放/DPMS 恢复原状。记录结果五个对照与五个动作片段全部通过无清理错误。下表时间为从故障派发起测量的单次观测值不是延迟分布或性能承诺观测到的清空状态时间包含状态查询延迟并非原生清理的精确瞬间时间逻辑见 desktop_state_evidence.py 的cancellation判定。故障MCP 拒绝观测到清空状态应用收到释放结果移动241.08 ms439.13 ms242.88 mscancelled缩放189.02 ms354.70 ms188.64 mscancelled真实会话锁60.96 ms130.60 ms76.52 mscancelledDPMS 熄屏64.40 ms263.39 ms66.47 mscancelled目标销毁7.03 ms299.71 ms不可接收stale_target十个结果均基于原始应用日志、动作响应、状态记录、主指针轨迹与窗口管理器快照在离线状态下重新计算。十个原始录像全部成功解码对统一视频采样与选定的故障/恢复帧进行了人工检查覆盖目标移动、缩放、消失、黑屏锁屏/熄屏区间与恢复过程。需要说明视频只是支持性证据不是计时基准。录像与事件日志并非逐帧同步——一次跨时钟换算尝试产生了无效采样位置因此人工检查改用视频本地时间戳且不修改原始录像。事件延迟来自单调时钟monotonic测试日志而非视频时间线。私有证据包保留了原始视频、逐文件摘要、通过/失败片段与搭建/构建记录操作日志、授权与机器相关证据不提交到公共仓库。支持性检查与保留的失败本轮验证同时记录了一批支持性结果与有价值的失败样本79 个 Python 辅助测试在宿主机与 Fleet 访客机上全部通过。7 个便携 CTest 在原生访客机与宿主机 Release 构建中全部通过包括启用NDEBUG的缓存几何回归。两次最初的移动片段在启用同步动作录制时超过了 750 ms MCP 响应界限约 865 ms 与 985 ms。原生释放本身是及时的但这些片段失败并被保留。最终矩阵改用独立观察服务并保持同一 750 ms 界限因此不主张任何「含录制开销的动作服务延迟」结论。无表面的锁夹具命中了 Hyprland 的缺面宽限并超过确认期限最终夹具为每个通告输出提供不透明黑色共享内存表面并等待真实协议确认恢复过程优雅锁客户端未被杀死。新启动的目标可能在搭建期抢占主焦点。插件正确撤销了该主指针冲突的授权搭建现在会在初始或恢复批准前恢复并断言精确的前台执行者。Driver 的精确窗口前台激活在 Hyprland 上显式拒绝由独立的主 seat 夹具在 Driver 观察的夹持下完成该授权搭建——搭建本身不是后台隔离证据。常规托管的 CI 只是这些聚焦原生结果的补充既不能认证合成器行为也不能替代规范的桌面矩阵。剩余门槛哪些仍未证明本轮覆盖的是原生 GTK 夹具不是新的真实应用或物理宿主认证因此不建立以下兼容性Chromium/Ozone、Electron、GTK4、Qt6、XWayland、subsurface、分数缩放、多监视器、广泛的输入法兼容性。动作片段每次只锻炼一条通道销毁场景检查了两条通道的资源计数但未做并发双通道故障投递。锁屏与 DPMS 是采样状态完全落在两次采样之间的 off/on 转换未被证明会撤销授权。Escape 恢复使用原子键包atomic key packet不是对按住键流的打断。这些连同最终候选上的完整规范桌面矩阵仍是独立的测试与设计门槛。生产环境的授权 UX、资源生命周期与热重载行为、能力感知观察、以及协议/RFC 决策都仍然开放。PR 保持 draft 状态这份证据不授权合并、发布、镜像发布或生产上线。复现指引完整复现需遵循 tests/README.md 的「Desktop-state fault controls」一节。核心命令形态为针对每个--case destroy|move|resize|lock|dpms先跑对照再跑动作# 先运行 fault-only 对照 python3 tests/desktop_state_live.py --case move --mode control \ --plan plan.json --evidence evidence-control --driver /path/to/cua-driver \ --driver-socket /path/to/driver.sock --input-directory /path/to/instance \ --module /path/to/cua-hyprland-plugin.so --primary-grab /path/to/primary_grab \ --background-journal bg-journal.jsonl --foreground-journal fg-journal.jsonl \ --foreground-wire fg-wire.log --source-sha 40-hex --compositor-pid pid \ --compositor-exe /usr/bin/Hyprland --instance sig --disposable \ --lock-fixture /path/to/session_lock_fixture --observer-driver-socket /path/to/observer.sock # 再以 --mode action --control 对照结果路径 运行动作片段前提包括一次性 Fleet 访客、显式加载的输入实验构建、--permission-mode unrestricted --dangerously-bypass-approvals的源码构建 Driver 服务、两个原生 GTK 夹具及其日志与 Wayland 线上日志。动作片段会输出GRANT_REQUIRED以及销毁场景的REPLACEMENT_REQUIRED由宿主机操作员用 input_operator.py 签署授权能力位仅10drag8 恢复键探测2私钥永不入访客机。授权签名格式与协议细节见输入实验协议说明。任何片段都必须保留失败运行与清理结果只发布脱敏的结果、时间、版本与摘要。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考