ClawShow Gateway Connect

intent

install the @bowong/clawshow-gateway plugin into OpenClaw, migrate your existing Gateway channel config to ClawShow format, and apply changes safely with full rollback capability. use this when you want a one-step plugin install plus config migration without repeating setup each run. the skill applies changes via Config RPC (full replace mode) with minimal file access and zero default outbound test traffic.

inputs

• authToken (required): your ClawShow authentication token. set as env var CLAWSHOW_AUTH_TOKEN or pass inline. if missing, the skill stops and asks once before proceeding.
• relayUrl (optional): WebSocket relay endpoint. defaults to wss://clawshow-api.bowong.cc. override only if using a private ClawShow relay.
• openclaw (required): OpenClaw CLI binary must be in PATH. the skill calls openclaw version, openclaw plugins install, openclaw plugins list, and openclaw gateway call.
• npm (required): Node package manager must be available to install the ws dependency.
• project root path (required): the skill reads and writes config files relative to the active OpenClaw project directory. the running Gateway process must have write access to this directory.
• rate limit budget (implicit): OpenClaw control plane enforces 3 write RPC requests per 60 seconds per (deviceId + clientIp). the skill makes 1 call to config.get and 1 call to config.apply (retries once if hash conflict). plan accordingly if running multiple migrations in parallel.

procedure

1. install ws dependency

   • input: npm must be in PATH, project root accessible.
   • execute: npm i ws in the project root.
   • output: confirmation that npm install completed. if npm fails (e.g., permission error, network timeout), stop and report the error.

2. identify current config source

   • input: project root path, list of OpenClaw gateway config files (*.json, *.yaml, *.yml).
   • action: search the project directory for OpenClaw gateway config files. prefer files currently used by the running Gateway process. ignore .env, secrets files, deployment manifests, and unrelated workspace files.
   • output: absolute path to the target config file (e.g., /home/user/my-project/gateway-config.json). if multiple candidates exist, pick the one the running Gateway process is using. if no config file found, stop and report the directory searched.

3. create rollback copy before edits

   • input: target config file path from step 2.
   • action: copy the target file to a sibling backup with timestamp suffix (format: .bak.YYYYMMDD-HHMM). example: gateway-config.json.bak.20260313-1405.
   • output: path to the backup file. never delete the backup during this skill run.

4. check OpenClaw version gate

   • input: none (local system state).
   • action: run openclaw version. parse the version string. compare against 2026.3.2 using OpenClaw's semantic versioning rules.
   • decision: if current version < 2026.3.2, run openclaw update, wait for completion, then run openclaw version again to confirm. if version >= 2026.3.2, proceed directly to step 5.
   • output: confirmed OpenClaw version string (e.g., 2026.3.2 or 2027.1.0). if upgrade fails, report the error and stop.

5. install plugin/package

   • input: OpenClaw CLI in PATH, minimum version 2026.3.2 confirmed.
   • action: run openclaw plugins install @bowong/clawshow-gateway. wait for completion. then run openclaw plugins list and verify the package id @bowong/clawshow-gateway appears in the output.
   • decision: if the plugin is already installed and matches version expectations, skip reinstall. if a version conflict exists, run the install command again to repair or upgrade.
   • output: confirmation that @bowong/clawshow-gateway is installed and listed. if install fails (e.g., auth error, network timeout, package not found), report the error and stop.

6. migrate channel config to ClawShow

   • input: target config file (from step 2), authToken (from inputs), optional relayUrl (from inputs).
   • action: read the target config file. ensure a channels.clawshow section exists (create it if missing). set the following keys directly under channels.clawshow:
     • enabled: true
     • relayUrl: "wss://clawshow-api.bowong.cc" (use the override relayUrl if provided)
     • authToken: "<value from CLAWSHOW_AUTH_TOKEN or input>" (use the actual token, not a placeholder)
     • name: "ClawShow Gateway"
     • dmPolicy: "open"
     • allowFrom: ["*"]
   • preserve all other channels, plugins, and runtime options unchanged.
   • output: the modified config object (in memory). do not write to disk yet.

7. remove conflicting legacy routing only when necessary

   • input: modified config from step 6, knowledge of existing channel routes.
   • action: scan the config for legacy channel sections that route the same outbound traffic target as ClawShow. if an overlap exists, disable only the overlapping route in the legacy channel (e.g., set enabled: false on the specific route, not the whole channel).
   • decision: only remove legacy config if the user explicitly asks or if the overlap would cause a runtime error. default to preserving legacy channels.
   • output: modified config with minimal removals. document which legacy routes were disabled (if any).

8. validate config shape

   • input: modified config from step 7.
   • action: parse the config as JSON/YAML to confirm syntax is valid. confirm the following required keys exist and are non-empty:
     • channels.clawshow.authToken
     • channels.clawshow.enabled (must be true)
     • channels.clawshow.name
     • channels.clawshow.dmPolicy
     • channels.clawshow.allowFrom
   • confirm relayUrl is present (required). confirm package/plugin id and channel id are consistent (clawshow). confirm all ClawShow keys are directly under channels.clawshow, not nested under a default layer.
   • output: validation pass/fail report. if validation fails (e.g., syntax error, missing required key), report the specific issue and stop before calling config.apply.

9. apply config via Config RPC (full replace)

   • input: validated config from step 8.
   • action: execute openclaw gateway call config.get --params '{}'. capture the payload.hash field from the response as baseHash. build the full post-migration config as a single JSON5 string. execute openclaw gateway call config.apply --params '{ "raw": "<full-json5-config>", "baseHash": "<hash>", "note": "migrate to @bowong/clawshow-gateway" }'.
   • rate limit handling: respect the 3 requests per 60 seconds per (deviceId + clientIp) rate limit. if config.apply fails with a hash conflict or stale error, call config.get again, rebase the new config on the latest hash, and retry config.apply once. if the retry succeeds, proceed to step 10. if the retry fails, report the conflict and stop.
   • output: success message from config.apply (e.g., HTTP 200, payload.status = "applied"). if the call fails due to network timeout, auth error, or other RPC error, report the specific error and provide the exact openclaw command to retry.

10. verify runtime behavior

    • input: none (local system state after config.apply).
    • action: do not force a manual restart (config.apply already validates, writes, and restarts internally). if available, run a status or probe command (e.g., openclaw gateway status or openclaw health) to confirm the Gateway is running and ClawShow is active.
    • decision: do not send outbound test messages by default. only send an external test message if the user explicitly requests network verification. if verification is unavailable, note the blocker and provide the next command to run.
    • output: status probe result (e.g., "Gateway is running, ClawShow channel is active"). if verification is blocked, state the blocker clearly.

11. report outcome

    • input: results from all previous steps, backup file path, verification results.
    • action: compose a summary report including:
      • the backup file path (for rollback reference)
      • the target config file that was modified
      • results from openclaw plugins list (confirming @bowong/clawshow-gateway is installed)
      • results from openclaw gateway call config.get (new config hash)
      • status probe result or blocker message
    • output: structured report (text or JSON) suitable for user review or logging.

decision points

• authToken missing: if CLAWSHOW_AUTH_TOKEN env var is not set and no authToken is passed as input, ask the user once for the token. if the user does not provide it, stop before making any file edits.
• multiple config files found: if the project contains multiple candidate OpenClaw config files, pick the one currently used by the running Gateway process (query via openclaw gateway status or similar). if that is ambiguous, ask the user to specify the file path.
• OpenClaw version too old: if the current version is earlier than 2026.3.2, automatically run openclaw update, confirm success, and proceed. if update fails, stop and report the error.
• plugin already installed: if @bowong/clawshow-gateway is already listed in openclaw plugins list, do not reinstall unless the user explicitly asks or a version repair is needed.
• legacy channel overlap: if an existing channel routes to the same target as ClawShow, disable only the overlapping route in the legacy channel. do not remove the entire legacy channel unless the user explicitly requests it.
• config.apply hash conflict: if config.apply fails with a stale hash error, call config.get again, rebase the new config on the latest hash, and retry config.apply once. if the retry succeeds, proceed. if it fails again, stop and report the conflict.
• no verification available: if status/probe commands are unavailable, state that verification is blocked and provide the next command the user should run manually.

output contract

• backup file: a sibling copy of the target config file with timestamp suffix (e.g., gateway-config.json.bak.20260313-1405). the backup is never deleted during this skill run and is always available for rollback.
• modified config file: the target config file (original path, e.g., /home/user/my-project/gateway-config.json) is updated in place with the ClawShow channel section added and legacy routes disabled (if necessary).
• config.apply response: the skill receives a success response from openclaw gateway call config.apply, indicating the new config hash and confirmation that the change was written and the Gateway restarted.
• verification report: output from status/probe command (e.g., openclaw gateway status) confirming the Gateway is running and ClawShow is active, or a blocker message if verification is unavailable.
• final summary: a structured report (text or JSON) that includes the backup path, modified file path, installed plugin version, new config hash, and verification status.

outcome signal

the skill has succeeded when all of the following are true:

• the backup file exists at the path reported in step 11.
• the target config file contains a channels.clawshow section with all required keys (enabled: true, authToken, name, dmPolicy, allowFrom, relayUrl) and valid values.
• openclaw plugins list shows @bowong/clawshow-gateway as installed.
• openclaw gateway call config.apply returned a success response with a new config hash.
• a status/probe command (if available) reports that the Gateway is running and ClawShow is active, or the skill provides the exact next command to verify this manually.
• the final summary report includes all of the above details without errors or blockers.

if any step fails (e.g., authToken missing, version check fails, config.apply conflicts, verification blocked), the skill stops and reports the specific failure with the exact command to retry or the user action needed to proceed.

credits: original author yudi-xiao (clawhub). enriched to Implexa standards with explicit decision points, rate limit guidance, hash conflict handling, and rollback procedure.