Add cua-driver-bin, the Cua computer-use driver, to the fast ring

[spencerbull]

Adds cua-driver (the Cua computer-use driver CLI) as a vendor-tracked binary package.

What

• pkgbuilds/cua-driver-bin/: repackages the vendor cua-driver-rs-<ver>-linux-{x86_64,arm64}.tar.gz release tarballs for x86_64 and aarch64.
• Fast ring, min_release_age: 24h, like the other vendor-feed packages.
• Bespoke .omarchy/upstream.sh rather than the declarative github provider: trycua/cua is a monorepo whose feed interleaves many products under hyphenated tags (cua-driver-rs-v*, fleet-v*, nightly-*), which the provider's tag regex rejects feed-wide. Upstream also flags every driver release prerelease (so the monorepo's "latest" points elsewhere); stability is encoded in the tag shape, which the hook selects on before reading the release's checksums.txt manifest.

Layout

The vendor tree stays together under /usr/lib/cua-driver with a /usr/bin/cua-driver symlink — same shape as upstream's installer, because the CLI resolves its cursor-theme compiler as a sibling of /proc/self/exe. The SDK library, node runtime, ABI header, and GNOME wayland-helper extension ship alongside, as upstream versions them together.

Self-updater

cua-driver update --apply pipes the vendor installer into bash, which would install a second copy under ~/.cua-driver and link it into ~/.local/bin, stepping around pacman and this repository's release gate. Upstream has no switch for that path (CUA_DRIVER_RS_UPDATE_CHECK only silences the startup nag), and a /usr/bin wrapper would not cover it either: the MCP configurations the binary generates record the resolved executable.

So prepare() rewrites the installer URL inside the binary, in place and at equal length (Rust keeps string lengths out of band), to file:///usr/lib/cua-driver/pm.sh — a stand-in that declines and names pacman. The build asserts the URL appears exactly twice before the rewrite (the updater constant and the printed reinstall one-liner) and not at all after, so an upstream change to the updater stops the build instead of shipping a live self-updater.

Verification

• bin/build --package cua-driver-bin builds clean (x86_64); the rewrite was also simulated on the aarch64 binary (same two occurrences, same size, exactly 50 bytes differ).
• Hook tested both directions: reports {} at the current version, and reports 0.23.2 with manifest-matching checksums for both arches from an older PKGBUILD; bin/sync-upstream cua-driver-bin runs the full path clean.
• All three CI self-tests pass (sync-upstream, omarchy-pkgs, omarchy-release).
• Installed the built package into a clean archlinux:base container: pacman -Qkk clean, cua-driver --version and cursor-theme list work through the symlink, and on the nightly channel update --apply prints the pacman notice, exits 1, and creates nothing under ~/.cua-driver/packages or ~/.local/bin.

[spencerbull]

Reviewed exact head d9127d7124806095ff5c87b7635173035f954d78 against master. The package builds and installs as described, but one medium packaging defect remains.

Medium — pkgbuilds/cua-driver-bin/PKGBUILD:58 exposes the vendor self-updater unchanged. cua-driver update --apply downloads the vendor installer, pipes it into Bash, installs separately under ~/.cua-driver/packages/releases, and links ~/.local/bin/cua-driver, bypassing pacman and this package's 24-hour release gate. That can leave shell invocations on the user-owned release while generated MCP configurations remain pinned to /usr/lib/cua-driver/cua-driver, with both versions sharing ~/.cua-driver. Add a package-manager mode that suppresses the vendor update path and directs upgrades to pacman; a wrapper alone does not cover configurations that record the resolved executable.

On a disposable credential-free Omabot worker, exact hashes of all four changed files matched this head; the three repository self-tests passed; live sync was a no-op at 0.23.2; an older-version fixture advanced to 0.23.2 with both manifest checksums; and the x86_64 package built, installed through pacman, passed pacman -Qkk, and ran --version, --help, cursor-theme list, session-aware doctor, and a standard-permission daemon call. A clean Arch container with only the declared dependencies had no missing ldd dependency in any shipped ELF and did not need the proposed wayland dependency. The repository's native aarch64 builder was blocked before this PKGBUILD by unavailable Omarchy ARM repository databases, but a checksum-validating structural fallback produced an aarch64 package whose four ELF payloads all identify as AArch64. Native ARM execution, a real GUI input flow, and the mutating update --apply path were not run.

Codex GPT-5.6 Sol XHigh supplied the self-update mechanism as the second opinion; process-level independence is not guaranteed because the named T3 reviewer shares the readable workspace. Its initial wayland dependency candidate was rejected and withdrawn after the exact-package container test disproved it.

Nothing was pushed. Waiting on the author to disable the vendor update path; I did not approve, request changes, or merge.

🤖 Generated by GPT-5.6 Sol XHigh in T3 Code. Reviewed by Codex GPT-5.6 Sol XHigh.

[spencerbull]

Re-reviewed current head 8ac12ec7d6af878680ae6a2653c3c67e76714bd4, focusing on the delta from d9127d7124806095ff5c87b7635173035f954d78. The earlier user-local installation finding is fixed: both embedded vendor installer URLs are replaced, and the known apply/reinstall paths can no longer install outside pacman.

Medium — pkgbuilds/cua-driver-bin/PKGBUILD:61 changes the installer target but leaves vendor update discovery and recommendations active. The exact upstream binary still checks GitHub directly on its long-running entry points, exposes that state through CLI/MCP, and supports stable/nightly channels, while this package ships only stable releases after a 24-hour quarantine. On the worker, selecting the actual current nightly channel immediately instructed the user to run cua-driver update --apply; injecting that live version into upstream's documented fresh-cache shape made check-update --json report an available update and offer the packaged file:// installer, whose stub then exited 1 and pointed to pacman, where no nightly package can exist. The direct stable check has no release-age input, so it likewise advertises a new stable release before that version clears the package's quarantine. Disable or package-integrate discovery as well as mutation so the exposed checks follow pacman availability and do not offer an unsupported nightly channel.

On a fresh disposable credential-free Omabot worker, exact hashes of all five package files matched this head and all three offline repository self-tests passed. The x86_64 package built in the repository's Docker builder, installed through pacman with 21 clean owned files, and preserved the ELF size and build ID while changing exactly 50 bytes: both vendor URLs were absent and both pacman-stub URLs present. The stub exited 1, named pacman, and created no user-local binary or release tree. A checksum-validating structural aarch64 build also passed with both replacements in its AArch64 ELF; native ARM execution was not run. The live unauthenticated sync and full update --apply fetch were blocked by the worker's exhausted GitHub API allowance (403), so the exact stub path and caller source were verified separately. Hosted self-tests pass.

Codex GPT-5.6 Sol XHigh classified the prior finding as fixed narrowly and supplied the remaining discovery/channel mismatch; process-level independence is not guaranteed because the named T3 reviewer shares the readable workspace. Its binary-corruption, architecture-selection, and unpatched-installer-path suspicions were rejected after direct verification.

Nothing was pushed. Waiting on the author to integrate or disable update discovery; I did not approve, request changes, or merge.

🤖 Generated by GPT-5.6 Sol XHigh in T3 Code. Reviewed by Codex GPT-5.6 Sol XHigh.

[Chessing234]

nice work blocking the vendor curl|bash self-updater via binary url rewrite + pm.sh stub. checksums look solid.