WristClaw - Smartwatch control channel for OpenClaw
WarnAudited by ClawScan on May 16, 2026.
Overview
This looks like a real smartwatch bridge, but it would run an unreviewed remote installer and allow pairing messages to create a persistent, broad-control channel with limited scoping.
Install only if you trust wristclaw.app and can inspect or verify the native installer. Pair only from a trusted, verified device/channel, avoid arbitrary relay URLs, and consider restricting this channel from sensitive tools such as file access, messaging, account actions, and live location until the skill documents clear approval and revocation controls.
Publisher note
This is enabling the user to use a new channel and communicate with an OpenClaw instance through a relay server from a Apple Watch app such as WristClaw.app. -- Initial public release. Apple Watch client + Telegram pairing flow + multimedia channel (text + audio + thumbnails). E2E encrypted via the wristclaw.app relay (BYO relay supported)
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Installing or pairing could execute unreviewed code on the user's machine from wristclaw.app.
The skill installs a native channel by piping a remote script directly to bash. The artifact set contains no installer code or pinning, and the registry summary says there is no install spec, making the executable supply chain under-reviewed.
cmd: "curl -fsSL https://wristclaw.app/install.sh | bash"
Inspect the installer before running it, publish a reviewed install spec or package with pinned checksums, and require explicit user approval before executing the installer.
A spoofed or mistaken pairing message could register a relay/session that gives an unintended party a route into the agent.
An inbound message from any channel can drive an OpenClaw channel-registration command using message-supplied URL and token values. The visible instructions do not require sender verification, relay validation, or a manual confirmation before changing channel configuration.
When Matt sends a message to any channel ... treat it as a wristclaw pairing payload ... openclaw channels add --channel wristclaw --url "<relayURL from payload>" --token "<sessionID from payload>"
Only accept pairing payloads from a verified user/channel, require an explicit local confirmation, validate or allowlist relay URLs, and display the exact relay/session before registration.
Agent requests and replies may flow through a relay/session whose origin or ownership is not clearly verified in the skill instructions.
The bridge depends on a relay-mediated peer channel, and the later registration step accepts the relay URL from the pairing payload. The artifacts do not show clear peer identity checks or relay-origin boundaries beyond the stated encryption design.
The watch talks to a stateless WSS relay (`wss://relay.wristclaw.app/ws`); the native `wristclaw` OpenClaw channel joins the same session as the host and the relay forwards encrypted frames between the two peers.
Bind pairing to a verified public key and trusted relay, document the identity checks performed by the native channel, and avoid accepting arbitrary relay URLs by default.
Anyone who can use the paired channel may be able to trigger sensitive account or local-data actions through the agent.
The skill gives wrist-originated turns broad delegated access, including local files, MCP tools, and live device-location data. Those capabilities are sensitive and are not bounded by clear per-action approvals or metadata-declared credentials.
You have your complete skill catalog, MCPs, web search, file system — all of it ... call the `findmyloc` skill. It pulls Matt's live FindMy device locations.
Restrict high-impact tools for watch-originated requests, require confirmation for location/file/account actions, and clearly declare the credentials and services the channel can access.
The watch channel may remain active after setup until the user removes or revokes it.
Registering and logging in a channel is expected for this type of skill, but it creates ongoing channel state and may restart the gateway. The visible documentation does not mention cleanup or unpairing.
openclaw channels login --channel wristclaw ... If the gateway was already running, restart it so it picks up the new channel session.
Document how to unpair, revoke tokens, remove the channel, and confirm which relay/session is currently active.