completed
lahfir/agent-desktop
Verified maintainerNative desktop automation CLI for AI agents. Control any application through OS accessibility trees with structured JSON output and deterministic element refs.
https://github.com/lahfir/agent-desktop632
Stars
26
Forks
3
Issues
Rust
Language
Apache-2.0
License
May 12, 2026
Last push
-
LOC
-
Files
This is a Rust desktop-automation CLI for AI agents on macOS. It drives apps through the Accessibility API and also ships a C-ABI cdylib (libagent_desktop_ffi) that Python/Swift/Go/Node hosts dlopen and call in-process. A few areas I'd appreciate extra eyes on: - FFI boundary: ownership, lifetime and threading rules around ad_adapter_create / ad_adapter_destroy and the ad_* entrypoints. I'm worried about UAF, double-free, or unsoundness if a host calls from multiple threads or drops the adapter mid-call. - Input handling on the CLI: the batch subcommand takes raw JSON, and several commands accept user-supplied strings (type, set-value, clipboard-set, launch by bundle id). I'd like a look at parsing, argument validation, and whether anything can end up shelling out or being interpreted. - Accessibility permission surface: since the binary effectively gets keystroke + click rights once granted, I want to make sure there's no path where an untrusted caller (e.g. a malicious skills doc or a crafted snapshot response) can trick the agent loop into acting on the wrong element. The @e ref system in particular — stale ref handling, ref reuse across snapshots. - Release artifacts: prebuilt FFI tarballs and the npm postinstall that downloads a binary. Worth checking checksum/Sigstore verification is actually enforced and not just documented. - General Rust hygiene: unsafe blocks (there have to be a bunch around CoreFoundation / AX APIs), panic safety across the FFI boundary, and any clippy lints that might've been silenced. No deadline. Apache-2.0, macOS 13+ only for now. Thanks!
Lahfir
This is a Rust desktop-automation CLI for AI agents on macOS. It drives apps through the Accessibility API and also ships a C-ABI cdylib (libagent_desktop_ffi) that Python/Swift/Go/Node hosts dlopen and call in-process. A few areas I'd appreciate extra eyes on: - FFI boundary: ownership, lifetime and threading rules around ad_adapter_create / ad_adapter_destroy and the ad_* entrypoints. I'm worried about UAF, double-free, or unsoundness if a host calls from multiple threads or drops the adapter mid-call. - Input handling on the CLI: the batch subcommand takes raw JSON, and several commands accept user-supplied strings (type, set-value, clipboard-set, launch by bundle id). I'd like a look at parsing, argument validation, and whether anything can end up shelling out or being interpreted. - Accessibility permission surface: since the binary effectively gets keystroke + click rights once granted, I want to make sure there's no path where an untrusted caller (e.g. a malicious skills doc or a crafted snapshot response) can trick the agent loop into acting on the wrong element. The @e ref system in particular — stale ref handling, ref reuse across snapshots. - Release artifacts: prebuilt FFI tarballs and the npm postinstall that downloads a binary. Worth checking checksum/Sigstore verification is actually enforced and not just documented. - General Rust hygiene: unsafe blocks (there have to be a bunch around CoreFoundation / AX APIs), panic safety across the FFI boundary, and any clippy lints that might've been silenced. No deadline. Apache-2.0, macOS 13+ only for now. Thanks!
2
Total findings
0
CRITICAL
2
HIGH
0
MEDIUM
0
HIGH_BUG
0
BUG
The full report is private to the requester and donor. Public pages only show safe summary metadata.