尧图网页设计 
在 Windows SSH 会话中 cua-driver 的 list_windows 返回空列表怎么排查【免费下载链接】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在一台 Windows 机器上通过 SSH 登录并执行cua-driver call list_windows时即使 RDP 会话里明明开着多个窗口命令也可能直接返回[]。这不是工具坏了而是 Windows OpenSSH 的会话隔离导致的典型现象sshd启动的 shell 落在 Session 0非交互式服务会话而窗口枚举相关的 Win32 API 只能看到调用者自己的 WindowStation/Desktop。这篇指南基于 Drive a Windows app over SSH 与 daemon 进程模型文档给出从确认现象到修复、再到验证的完整排查路径。先确认现象是不是 Session 0 问题SSH 侧先跑cua-driver doctor。文档给出的 Windows 会话探针会直接报告这个状态示例输出文档示例如下[warn] interactive session: running in Session 0 (services); window-driving tools (list_windows, click, type_text, get_window_state) will return empty results. These APIs need an attached interactive desktop.只要看到这条[warn]问题就锁定为当前进程没有附加交互桌面。此时list_windows返回空是预期行为修复方向是把守护进程daemon放到 Session 1 的交互会话里让 SSH 侧只负责传协议消息。目标架构源文档原图┌───────────────────────────────────────────────────────────────┐ │ Session 1 (RDP / console, has interactive desktop) │ │ │ │ cua-driver-serve (autostart Scheduled Task) │ │ ↑ │ │ │ named pipe: \\.\pipe\cua-driver │ └──────┼────────────────────────────────────────────────────────┘ │ ┌──────┼────────────────────────────────────────────────────────┐ │ Session 0 (services / SSH, no desktop) │ │ cua-driver mcp │ │ cua-driver call list_windows │ └───────────────────────────────────────────────────────────────┘排查顺序版本、daemon、会话状态、MCP 端点官方文档列出的排查清单打开 issue 之前依次确认版本是否一致在 SSH 侧执行cua-driver --version确认报告的是你期望的当前安装。需要升级时用irm https://cua.ai/driver/install.ps1 | iex这是远程安装脚本执行前请确认来源可信。daemon 是否在运行SSH 侧执行cua-driver status确认报告了一个运行中的 daemon。如果没有用cua-driver autostart status查看计划任务是否已注册。autostart status各取值的含义见 keep-running 指南 与 WINDOWS skill 文档not-registered—— 任务确实不存在需要重新cua-driver autostart enableregistered (not running)—— 任务存在但 daemon 没起用cua-driver autostart kick启动registered (running)—— 正常状态permission-denied/unknown—— 当前进程无法查询任务计划程序命令退出码非零并保留原始诊断。此时不要盲目重新注册应换一个能读取该任务的上下文再查。交互会话是否存在执行query session确认你的用户有一行处于Active或Disc状态文档示例query session # SESSIONNAME USERNAME ID STATE TYPE # rdp-tcp#23 you 2 Active从未在这台机器上过 RDP 的话先连一次 RDP下次登录时 autostart 触发器会自动触发。RDP 断开Disc后会话仍然存活daemon 只在显式登出或重启时停止。从 RDP 侧确认桌面附加从 RDP 执行cua-driver doctor确认报告[ok] interactive session: session N has an attached interactive desktop。MCP 端点是否显式指向 daemonMCP 命令必须带--socket \\.\pipe\cua-driver或cua-driver status报告的实际端点。裸的cua-driver mcp不带--socket在 Windows 上会拥有自己的直连 runtime在 Session 0 中 fail closed不会静默回退到别的会话。修复路径在交互会话里注册并启动 daemon确认根因是 Session 0 后修复步骤是**从交互会话RDP 或本地控制台**执行cua-driver autostart enable cua-driver autostart kickenable注册一个名为cua-driver-serve、LogonType: Interactive的计划任务。Interactive是必需的S4U、Password等替代登录类型会把 daemon 放进 Session 0GUI 工具同样会返回空数组。命令是幂等的升级后重跑会自动更新二进制路径。kick立即启动任务不用等下次登录。kick需要一个处于 Active 的交互会话才能把 daemon 放进 Session 1用query session先确认。不要从 SSH 侧执行enable在非交互上下文SSH、Session 0 的SYSTEM中执行会失败并报出难以理解的No mapping between account names and security IDs was done错误——请改用 RDP 或本地控制台。结果验证修复完成后回到 SSH 会话验证 daemon 可达文档示例输出cua-driver status # Cua Driver daemon is running # socket: \\.\pipe\cua-driver # pid: 12345 # session: 2 ← daemon 在你的交互会话中session字段是关键判据它应指向你的交互会话1而不是 0。随后直接调用工具cua-driver call list_apps # 等价显式形式 cua-driver call list_apps --socket \\.\pipe\cua-drivercua-driver call默认就解析默认命名管道--socket用于需要显式指定端点时。MCP 侧则要把命令显式指向该 daemonclaude mcp add --transport stdio cua-driver -- cua-driver.exe mcp --socket \\.\pipe\cua-driver如果显式选择的交互会话 daemon 不可用MCP 启动会直接失败而不会试图从 SSH 会话做 GUI 操作——看到启动失败时应回到上面的排查清单而不是去掉--socket。排除会话问题后仍为空的两种情况如果doctor已确认进程在交互会话中、daemon 会话正确但list_windows仍异常还有两个文档明确记录的独立现象见 WINDOWS 故障排查UWP / WebView2 窗口缺失非完全空UIA 桌面枚举可能因某个 provider 无响应而降级list_windows会退回仅 Win32 输出而不是挂起。执行cua-driver doctor并在 provider 恢复后重试。launch_app返回了 pid 但list_windows({pid})为空UWP 冷启动竞态AppFrame HWND 尚未生成。500ms 后重试list_windows({pid: N})若长期如此改用在list_windows({})全量输出中按应用名定位窗口。注意区分这两者与 Session 0 问题前两种发生在交互会话内、窗口部分可见或延迟可见Session 0 问题是全部窗口都不可见且doctor有明确的[warn]报告。补充doctor 检查项与限制任何工具调用返回异常时都值得跑一次cua-driver doctor它报告的内容包括见 诊断章节daemon 版本与安装路径、当前会话 ID必须 ≥1、COM 单元状态STA / MTA / 未初始化、UIA 可达性、AppX broker 可达性、cua-driver是否在 PATH 上、autostart 计划任务状态。多数失败都能追溯到其中某一项读到 false。两个值得记住的限制桌面级入口点serve、直连 MCP、CuaDriver.create()在没有附加交互桌面时会拒绝接受操作而list-tools、describe、dump-docs这类有限检查命令在 Session 0 中仍然可用——所以CLI 还能跑但看不到窗口本身就是 Session 0 的典型指纹。SSH 侧进程与交互侧 daemon 之间共享的是同一物理机器的屏幕与输入通道多个 MCP 客户端要共享同一个 daemon 时必须都显式传同一个cua-driver mcp --socket endpoint不要依赖环境发现。【免费下载链接】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），仅供参考 在 Windows SSH 会话中 cua-driver 的 list_windows 返回空列表怎么排查？
在 Windows SSH 会话中 cua-driver 的 list_windows 返回空列表怎么排查【免费下载链接】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在一台 Windows 机器上通过 SSH 登录并执行cua-driver call list_windows时即使 RDP 会话里明明开着多个窗口命令也可能直接返回[]。这不是工具坏了而是 Windows OpenSSH 的会话隔离导致的典型现象sshd启动的 shell 落在 Session 0非交互式服务会话而窗口枚举相关的 Win32 API 只能看到调用者自己的 WindowStation/Desktop。这篇指南基于 Drive a Windows app over SSH 与 daemon 进程模型文档给出从确认现象到修复、再到验证的完整排查路径。先确认现象是不是 Session 0 问题SSH 侧先跑cua-driver doctor。文档给出的 Windows 会话探针会直接报告这个状态示例输出文档示例如下[warn] interactive session: running in Session 0 (services); window-driving tools (list_windows, click, type_text, get_window_state) will return empty results. These APIs need an attached interactive desktop.只要看到这条[warn]问题就锁定为当前进程没有附加交互桌面。此时list_windows返回空是预期行为修复方向是把守护进程daemon放到 Session 1 的交互会话里让 SSH 侧只负责传协议消息。目标架构源文档原图┌───────────────────────────────────────────────────────────────┐ │ Session 1 (RDP / console, has interactive desktop) │ │ │ │ cua-driver-serve (autostart Scheduled Task) │ │ ↑ │ │ │ named pipe: \\.\pipe\cua-driver │ └──────┼────────────────────────────────────────────────────────┘ │ ┌──────┼────────────────────────────────────────────────────────┐ │ Session 0 (services / SSH, no desktop) │ │ cua-driver mcp │ │ cua-driver call list_windows │ └───────────────────────────────────────────────────────────────┘排查顺序版本、daemon、会话状态、MCP 端点官方文档列出的排查清单打开 issue 之前依次确认版本是否一致在 SSH 侧执行cua-driver --version确认报告的是你期望的当前安装。需要升级时用irm https://cua.ai/driver/install.ps1 | iex这是远程安装脚本执行前请确认来源可信。daemon 是否在运行SSH 侧执行cua-driver status确认报告了一个运行中的 daemon。如果没有用cua-driver autostart status查看计划任务是否已注册。autostart status各取值的含义见 keep-running 指南 与 WINDOWS skill 文档not-registered—— 任务确实不存在需要重新cua-driver autostart enableregistered (not running)—— 任务存在但 daemon 没起用cua-driver autostart kick启动registered (running)—— 正常状态permission-denied/unknown—— 当前进程无法查询任务计划程序命令退出码非零并保留原始诊断。此时不要盲目重新注册应换一个能读取该任务的上下文再查。交互会话是否存在执行query session确认你的用户有一行处于Active或Disc状态文档示例query session # SESSIONNAME USERNAME ID STATE TYPE # rdp-tcp#23 you 2 Active从未在这台机器上过 RDP 的话先连一次 RDP下次登录时 autostart 触发器会自动触发。RDP 断开Disc后会话仍然存活daemon 只在显式登出或重启时停止。从 RDP 侧确认桌面附加从 RDP 执行cua-driver doctor确认报告[ok] interactive session: session N has an attached interactive desktop。MCP 端点是否显式指向 daemonMCP 命令必须带--socket \\.\pipe\cua-driver或cua-driver status报告的实际端点。裸的cua-driver mcp不带--socket在 Windows 上会拥有自己的直连 runtime在 Session 0 中 fail closed不会静默回退到别的会话。修复路径在交互会话里注册并启动 daemon确认根因是 Session 0 后修复步骤是**从交互会话RDP 或本地控制台**执行cua-driver autostart enable cua-driver autostart kickenable注册一个名为cua-driver-serve、LogonType: Interactive的计划任务。Interactive是必需的S4U、Password等替代登录类型会把 daemon 放进 Session 0GUI 工具同样会返回空数组。命令是幂等的升级后重跑会自动更新二进制路径。kick立即启动任务不用等下次登录。kick需要一个处于 Active 的交互会话才能把 daemon 放进 Session 1用query session先确认。不要从 SSH 侧执行enable在非交互上下文SSH、Session 0 的SYSTEM中执行会失败并报出难以理解的No mapping between account names and security IDs was done错误——请改用 RDP 或本地控制台。结果验证修复完成后回到 SSH 会话验证 daemon 可达文档示例输出cua-driver status # Cua Driver daemon is running # socket: \\.\pipe\cua-driver # pid: 12345 # session: 2 ← daemon 在你的交互会话中session字段是关键判据它应指向你的交互会话1而不是 0。随后直接调用工具cua-driver call list_apps # 等价显式形式 cua-driver call list_apps --socket \\.\pipe\cua-drivercua-driver call默认就解析默认命名管道--socket用于需要显式指定端点时。MCP 侧则要把命令显式指向该 daemonclaude mcp add --transport stdio cua-driver -- cua-driver.exe mcp --socket \\.\pipe\cua-driver如果显式选择的交互会话 daemon 不可用MCP 启动会直接失败而不会试图从 SSH 会话做 GUI 操作——看到启动失败时应回到上面的排查清单而不是去掉--socket。排除会话问题后仍为空的两种情况如果doctor已确认进程在交互会话中、daemon 会话正确但list_windows仍异常还有两个文档明确记录的独立现象见 WINDOWS 故障排查UWP / WebView2 窗口缺失非完全空UIA 桌面枚举可能因某个 provider 无响应而降级list_windows会退回仅 Win32 输出而不是挂起。执行cua-driver doctor并在 provider 恢复后重试。launch_app返回了 pid 但list_windows({pid})为空UWP 冷启动竞态AppFrame HWND 尚未生成。500ms 后重试list_windows({pid: N})若长期如此改用在list_windows({})全量输出中按应用名定位窗口。注意区分这两者与 Session 0 问题前两种发生在交互会话内、窗口部分可见或延迟可见Session 0 问题是全部窗口都不可见且doctor有明确的[warn]报告。补充doctor 检查项与限制任何工具调用返回异常时都值得跑一次cua-driver doctor它报告的内容包括见 诊断章节daemon 版本与安装路径、当前会话 ID必须 ≥1、COM 单元状态STA / MTA / 未初始化、UIA 可达性、AppX broker 可达性、cua-driver是否在 PATH 上、autostart 计划任务状态。多数失败都能追溯到其中某一项读到 false。两个值得记住的限制桌面级入口点serve、直连 MCP、CuaDriver.create()在没有附加交互桌面时会拒绝接受操作而list-tools、describe、dump-docs这类有限检查命令在 Session 0 中仍然可用——所以CLI 还能跑但看不到窗口本身就是 Session 0 的典型指纹。SSH 侧进程与交互侧 daemon 之间共享的是同一物理机器的屏幕与输入通道多个 MCP 客户端要共享同一个 daemon 时必须都显式传同一个cua-driver mcp --socket endpoint不要依赖环境发现。【免费下载链接】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），仅供参考