[DISCUSS] Ship Cua Driver or keep maka-cu for macOS Computer Use?

[Astro-Han]

@hqhq1025 @M4n5ter, I'd like your read on the executor switch and the bundled binary's licensing.

Maka's macOS build still selects maka-cu, but the packaged release gate is off because there is no signed, distributable executor artifact. I tried bundling Cua Driver in draft PR #5611, then closed the PR to discuss the direction first. This also follows #3618, where I set aside a proposed maka-cu change for its own discussion.

The Cua prototype runs a pinned CLI behind the existing maka_computer tool and Runtime Host. Users would not have to install Cua or configure MCP. I prefer that shape, but it is not a straight swap: the prototype lacks menu expansion, text selection, minimize, and WebContent generation handling. I have not built and tested a signed, notarized Maka app on a real Mac.

For input, I would keep background as the default. If an action needs foreground, the tool would say so. The agent would explain the app, window, and exact action in chat, wait for the user's explicit agreement, observe again, and use foreground for that action only. No automatic fallback or separate approval store.

I also checked the dependency licenses and packaged notices. Besides MIT code, the macOS dependency graph includes MPL-2.0 UniFFI crates, and the CLI embeds an OFL-licensed Inter font. The proposed binary package carries their license texts and a visible label; the source release excludes the Cua executable and font binary. I found no concrete ASF or Apple SDK redistribution blocker, though the upstream executable has no source-to-binary attestation. If I missed a license obligation, could you point me to the component and term? Is there a simpler compliant package?

What would you choose: make maka-cu distributable, switch to bundled Cua, or take another route? If Cua is the choice, which missing actions must be restored before switching? Does the foreground flow above give users enough control, and would a temporary period with both executors help?

I will keep #5611 closed while this is discussed. If the direction holds, I can update that implementation and its real-device checks before reopening it for review.

Codex helped with the prototype, dependency audit, and this draft. I reviewed the post.

[M4n5ter]

English

Thanks for laying out the trade-offs. I support switching macOS Computer Use to a pinned, bundled Cua Driver behind the existing maka_computer and Runtime Host boundary. I prefer a single change that replaces maka-cu outright, with no period in which both executors are maintained. Cua can be qualified on the PR branch before that change is merged.

I reviewed the pinned 0.28.2 dependency graph and notices and found no licensing blocker to this direction. Before shipping, the macOS binary package needs a LICENSE that identifies Cua and its bundled third-party components, including UniFFI and the Inter font, and points to their license texts. Its notices should reflect what is actually bundled, rather than the entire build dependency graph.

Before merging the switch, please test a signed and notarized Maka app on a real Mac, including permissions and background/foreground behavior. Menu expansion, text selection, and stale WebContent handling should be restored or brought back for an explicit decision about the gaps. Minimize can follow later if no supported flow depends on it.

I agree with background by default, fresh observation, explicit consent for one foreground action, and no automatic fallback. If we promise that consent as a guarantee, the host should enforce it; tool instructions alone cannot. With those checks complete, I support reopening #5611 as the single-step replacement.

中文

感谢把这些取舍摆出来。我支持将 macOS Computer Use 切换到固定版本、随 Maka 打包的 Cua Driver，继续通过现有的 maka_computer 和 Runtime Host 使用。我倾向于在一次变更中直接替换 maka-cu，不设置两套执行器并存的过渡期。可以先在 PR 分支上完成 Cua 验证，再合并这次切换。

我核对了固定的 0.28.2 依赖图和许可说明，没有发现阻止采用 Cua 的许可问题。发布前，macOS 二进制包需要一份列明 Cua 及实际打包的第三方组件（包括 UniFFI 和 Inter 字体）、并指向各自许可全文的 LICENSE。随包说明也应对应实际打包内容，而非将完整构建依赖图直接视为二进制内容。

合并切换前，请在真实 Mac 上测试已签名、公证的 Maka app，包括系统权限和后台、前台操作。菜单展开、文本选择以及 WebContent 变化后的处理应恢复；若要保留缺口，需要再明确讨论。若现有受支持流程不依赖最小化操作，它可以后续补上。

我赞同默认后台操作；需要前台时，重新观察目标、取得用户对该次操作的明确同意，且不自动回退到前台。如果将同意描述为技术保证，就需要由宿主程序执行检查，不能只依赖工具说明。完成这些验证后，我支持将 #5611 作为一次性替换重新开放。