Grok

Nexting Devices integration

Step into Grok from physical hardware

Keep sessions and credentials on a trusted Host. Send only one-time decisions and live state to nearby keys, LEDs, or a display.

What you can do today

This is the frozen, testable public surface between Grok and Nexting Devices today.

Approve or denyAnswer an eligible one-time approval with two physical keys.Published · approval/1
See live stateShow thinking, working, needs-input, complete, or error on LEDs or a display.Published · status/1
Connect complete physical controlsNavigation, command keys, rotary input, push-to-talk, text, usage, and remote configuration now have frozen profiles.SDK 0.3 · Published
The protocols are published, but App Store 2.4 does not yet enroll third-party developer devices. Use the public protocol and firmware checks for current device validation.

How it works

  1. Agent asks

    Grok reaches a one-time action that needs user judgment.
  2. Trusted Host filters

    The Host checks request type, choices, and risk fields, then sends only an eligible bounded summary.
  3. Hardware answers

    The user operates a developer-mapped physical control; the device returns only the allow or deny choice for the current request.
  4. Agent continues

    The Host authoritatively commits the answer, resolves hardware state, and the same Agent session continues.
Developer-mapped physical controlMappingUser outcome
Your mapped confirm controlapproval/1 → allowApprove the current one-time request
Your mapped cancel controlapproval/1 → denyDeny the current one-time request
LED / screen rowstatus/1 → slotSee one volatile Agent state

Why this connection is trustworthy

Trust comes from LE Secure Connections and encrypted GATT, local Host credential isolation, minimum disclosure, and expiry, replay, and single consumption checks. Developer Reference Just Works is encrypted pairing; production still needs authenticated application identity.

ControlNexting implementation boundary
BLE LE Secure ConnectionsThe local device link uses BLE LE Secure Connections and encrypted GATT permissions for control traffic.
opaque request IDAgent credentials and internal account or session routes stay on the trusted Host; firmware receives bounded profile data such as an opaque request ID.
single consumptionThe Host checks authorization, expiry, sequence/revision, duplicate or replay state, and single consumption.
state and partial-frame clearing on disconnectDisconnect, reboot, a new bond, reset, or Host revocation clears the applicable volatile state and partial frames.
voice/1voice/1 controls the Host microphone lifecycle and never carries audio bytes or transcripts.
Just WorksDeveloper Reference Just Works pairing encrypts the link but production needs authenticated application identity and signed firmware.

Technical contract

The device speaks BLE only to a Nexting Host. The Host translates a bounded approval into a Grok session action. Firmware stores no Agent credentials and parses no prompts.

Official integration surface

Nexting's rich integration is built on the official Grok CLI Agent Client Protocol. The TUI stays local to the user's computer. The Host projects only eligible session/request_permission prompts onto approval/1. The device never connects to grok.com and never receives Grok credentials or internal session IDs.

Official requestEligible for approval/1Allow choiceDeny choice
session/request_permissionOnly a one-time permission that answers with allow true / false; no session-wide Always Approve{"allow":true}{"allow":false}
always-approve · unknown option setNever; keep on phone or desktop——
Session-wide always-approve, unknown option sets, incomplete fields, and already-answered requests stay off the reference approval controller. The Host retracts the matching BLE request when official ACP withdraws that permission.

Approval exchange

Host ↔ devicejson
Host → device   {"v":1,"t":"present","id":"3bb7","sum":"Allow git push?","opt":["allow","deny"],"ttl":30000}
device → Host   {"v":1,"t":"answer","id":"3bb7","ch":"allow"}
Host → device   {"v":1,"t":"resolved","id":"3bb7","r":"answered"}

A firmware key handler calls nexting_device_state_choose(&approval, NEXTING_DEVICE_CHOICE_ALLOW, now_ms(), &answer), then encodes and notifies. The SDK owns countdown, one-second retry, and resolution state.

Status display

The device declares one to eight statusSlots in Device Info. Slots absent from a frame are empty; disconnect clears all state.

Status frame

Host → devicejson
{"v":1,"t":"status","agents":[{"slot":0,"state":"thinking","label":"fix login bug"}]}

Complete physical control surface

These seven profiles ship together in the SPEC, shared vectors, C99, and JavaScript reference. Devices report generic physical events; the official App's Agent adapter still decides whether a key means fork, send, fast, or another action.

ProfileDirectionWhat hardware can doMessages
navigation/1BothMulti-option navigation and selectionnav_present · nav_move · nav_select · nav_resolved
keys/1BothGeneric key events, labels, and lightingkeymap · key_event
rotary/1BothSession and model switchingrotary_map · rotary_event · rotary_press
voice/1BothStart, stop, or cancel push-to-talkvoice_event · voice_state
text/1Host → deviceRender bounded plain texttext
usage/1Host → deviceShow model and usage countersusage · usage_clear
config/1BothAtomically update keys, lighting, and display preferencesconfig · config_result
voice/1 carries push-to-talk control only, never audio or transcripts. Recording, permission, and transcription belong to the Host microphone and Host App. The device also receives no Agent credentials, internal session IDs, or account data.

Key and rotary events

device → Hostjson
{"v":1,"t":"key_event","slot":3,"event":"press","seq":18}
{"v":1,"t":"rotary_event","slot":0,"delta":1,"seq":19}
{"v":1,"t":"voice_event","event":"start","seq":20}

seq lets the Host discard replayed or out-of-order input. Device Info must declare the key, rotary control, and profile first; the Host sends and accepts no undeclared profile.