OpenClaw

Connect OpenClaw in Settings → OpenClaw on desktop or mobile. Then choose OpenClaw in desktop’s Start thread → Run on, or mobile’s Jot actions → Hand off → OpenClaw. Progress, results, and follow-up messages stay in a saved Sharick thread.

Prepare your gateway

Enable hooks on your OpenClaw gateway and expose an HTTPS hooks URL reachable from the device running Sharick. A private VPN URL works while that device is connected to the VPN. Use a dedicated hooks token, not your Gateway login token.

Merge these settings into your existing configuration, choosing your actual agent ID and a long random token:

{
  "hooks": {
    "enabled": true,
    "token": "<dedicated-random-hook-token>",
    "path": "/hooks",
    "allowedAgentIds": ["main"],
    "allowRequestSessionKey": true,
    "allowedSessionKeyPrefixes": ["sharick:", "hook:"]
  }
}

Sharick uses sessionMode: "persistent" and a stable sharick:<thread ID> session key. This requires an OpenClaw version supporting persistent hook sessions. See the official hooks configuration. Apply gateway changes through your deployment’s normal configuration procedure.

Connect and verify reporting

1. Enter your hooks base URL, for example https://gateway.example/hooks, the hooks token, and optionally an agent ID. Sharick appends /agent.
2. Save the connection and allow OpenClaw to report to Sharick.
3. On mobile, Sharick first checks the hooks URL and token with an empty request that does not launch an agent. A failed check stops setup before creating a reporting thread.
4. Sharick sends a small verification task. OpenClaw reads the scoped reporting endpoint and sends a real completion callback. Setup stays incomplete until that callback arrives.

The gateway token is stored on the current device: encrypted storage in Sharick Desktop and secure device storage on mobile. It is not uploaded to Sharick’s server. Configure each device separately. When using a different gateway URL, enter its token again.

How reporting works

Each thread gets a dedicated reporting capability. OpenClaw can read that thread and append progress, questions, results, or corrections; it does not receive your Sharick login or access to unrelated threads. The server stores only a hash of the capability. Treat the OpenClaw session history as private, because the task includes this scoped credential.

The handoff includes reporting instructions automatically. It does not require installing a skill or configuring a full-account MCP API key just to return results. Existing Sharick MCP workflows can still be configured separately when an agent needs broader tools; see the MCP guide.

Hook admission means the gateway accepted the request, not that work is done. Only agent reports appear as progress or completion. deliver: false suppresses OpenClaw’s external-channel announcement; it does not disable Sharick reporting. Model and token usage are shown only when available, never inferred from admission.

Delivery and recovery

Sharick records each message before sending it and reserves its dispatch once. If a request times out, delivery is unconfirmed. Check the thread and gateway before deliberately sending another message. Sharick does not automatically redispatch an uncertain request when you reopen a thread.

• Rejected request: check the hooks token, agent allowlist, and persistent session settings.
• No reporting callback: ensure the OpenClaw agent can make HTTPS requests to Sharick and follows the reporting instructions. A gateway admission response alone cannot verify reporting.
• Read from another device: threads are saved to your Sharick account. Connect that device to your gateway before sending follow-up messages.

Reporting credentials can be revoked through the authenticated DELETE /api/v1/openclaw/threads/<thread ID>/credential endpoint. Revocation is recorded in the thread history and stops further use of those credentials.