Local pairing, capabilities, and availability

Pairing is a user-controlled flow, not an Agent task. The desktop app opens the authenticated browser authorization flow; the platform creates a one-time pairing code, and the desktop app claims it to bind the device. The Agent must ask the user to complete that flow and cannot pair itself or handle pairing credentials.

Device capability opt-in is persisted by the platform and does not reset merely because the app restarts. Each Agent grant is per-device and per-Agent, and one Agent can be assigned to only one desktop device. The current runtime’s advertised capabilities are intersected with persisted opt-in and the Agent grant. Disabling a device capability preserves its dormant Agent grant so re-enabling it restores access; the Agent-access UI shows such grants disabled and offers an explicit reauthorize-all-current-capabilities action. Revoking or killing a device disconnects and cancels active calls, revokes active approval bypasses, and makes local actions unavailable; revocation also removes Agent assignments.

Diagnose LOCAL_DESKTOP_NOT_CONNECTED by asking the user to open or pair the desktop app. LOCAL_CAPABILITY_UNAVAILABLE means the live desktop does not advertise the required capability, so check the desktop switch and any local OS permission. LOCAL_CAPABILITY_NOT_GRANTED means the persistent device/Agent authorization does not allow it, so adjust the device opt-in or Agent grant. LOCAL_CAPABILITY_CHECK_FAILED is a temporary authorization-check failure; report it rather than guessing.

Related actions

arinova.local.fs.read_file, arinova.local.shell.run, arinova.local.screen.capture

Also known as

pair desktop, desktop offline, computer control tool offline, capability opt-in, agent desktop grant, unavailable local tool, device revoked

---

Machine-readable Markdown · Knowledge index