カーソルはそのまま、アプリだけ動かす　HNが見たbackground computer-useの土台

Hacker NewsがCuaを受け取った空気は、「面白いデモ」より「ようやく欠けていた配管が出てきた」に近い。Show HNスレッドでFrancesco Bonacciが置いた問題設定はかなり明快だ。いまのGUI自動化はたいてい人間のセッションを乗っ取る。カーソルが飛び、focusが奪われ、windowが前に出てきて、agentが終わるまでユーザーは待つしかない。coding agentやcomputer-useが広がる2026年の文脈では、これは見た目の煩わしさでは済まない。一台のマシンを人間と複数agentで安全に共有できない、根っこの制約だ。

cua-driverは、その制約を真正面から崩そうとするmacOS向けのopen-source driverだ。agentが実際のMacアプリをクリックし、入力し、読んでいても、ユーザーは前面で作業を続けられる。だが実装はまっすぐではない。公開された 技術記事 によれば、CGEventPost はHID経由なのでカーソルを動かしてしまう。CGEvent.postToPid はカーソルを動かさないが、Chromium側で信頼されずクリックが落ちる。対象windowを先にアクティブにすればクリックは通るが、今度はfocusを奪い、Spaceまで引き寄せてしまい、background化の意味が消える。

Cuaの答えはmacOS内部の未公開経路を使うことだった。軸にあるのはSkyLightの SLEventPostToPid、yabai由来のfocus-without-raiseパターン、そして隠れたElectron windowでもAX treeを生かし続けるprivate accessibility hookだ。さらに (-1, -1) へのprimer clickまで出てくる。Chromiumのuser-activation gateを先に一度進めてから、本命のクリックをwindowを前に出さずに通すやり方だ。Bonacciが繰り返すのもそこだ。background computer-useは一社のagent製品の見せ場ではなく、どのharnessでも使える共通基盤であるべきだという主張である。

HNの反応もその見方にかなり乗っていた。元Appleエンジニアのコメントは実装を高く評価し、複数のUI automation flowを同時に走らせられる点を大きな勝ちとして挙げた。別のコメントはすぐ次の論点へ進んだ。telemetryの既定値、WindowsやLinuxにも似たprimitiveが必要になるのか、監査証跡をどう説明するのか。技術記事自身が認める制限もある。Chromiumのright-click問題や、Blenderのようなcanvas系アプリではなおfrontmost activationが要ることだ。それでもHNはこれを単なるMac小技として扱わなかった。agentが現実のデスクトップを並行して使う時代に向けた、かなり早い段階の基盤として見ていた。