---
{
  "id": "platform.local.pairing-capabilities-and-availability",
  "topic": "local",
  "title": "Local pairing, capabilities, and availability",
  "locale": "en",
  "version": "2026-08-23",
  "summary": "Pairing, persisted device opt-in, per-Agent grants, and live runtime capabilities must all agree before a local tool is available.",
  "content": "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.\n\nDevice 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.\n\nDiagnose `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.\n",
  "aliases": [
    "pair desktop",
    "desktop offline",
    "computer control tool offline",
    "capability opt-in",
    "agent desktop grant",
    "unavailable local tool",
    "device revoked"
  ],
  "tags": [
    "local",
    "pairing",
    "capabilities",
    "availability"
  ],
  "relatedActions": [
    "arinova.local.fs.read_file",
    "arinova.local.shell.run",
    "arinova.local.screen.capture"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/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.