@clawling/clawchat-plugin-openclaw 2026.8.27-1 → 2026.8.27-2

package/dist/src/skill-update.js

@@ -66,7 +66,7 @@ export const OFFICIAL_SKILLS_BASE = "https://raw.githubusercontent.com/clawling/
  * in the install-cli repo, bump this constant, ship it. `liveware-sample.ts`
  * imports the same ref, so the `livewares` tree at that tag is pinned too.
  */
-export const DEFAULT_SKILLS_REF = "skills-v1.6.0";
+export const DEFAULT_SKILLS_REF = "skills-v1.7.0";
 /** Refuse to treat an absurdly large response as a skill file (defence in depth). */
 export const MAX_SKILL_BYTES = 256 * 1024;
 /** This adapter's host target inside `skills/manifest.json`. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clawling/clawchat-plugin-openclaw",
-  "version": "2026.8.27-1",
+  "version": "2026.8.27-2",
   "description": "OpenClaw ClawChat channel plugin",
   "license": "MIT",
   "author": "CLAWLING PTE. LTD.",

package/skills/clawchat-liveware/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: clawchat-liveware
-version: 1.1.0
-description: Use when the user wants to expose this agent's local web service to the public internet via the liveware CLI and make it appear as an app in their ClawChat chat with this agent. Covers logging in to liveware with the ClawChat account, creating a liveware app, binding a tunnel to a local port, and registering the public URL to ClawChat.
+version: 1.2.1
+description: Use when the user wants to expose this agent's local web service to the public internet via the liveware CLI and make it appear as an app in their ClawChat chat with this agent. Covers logging in to liveware with the ClawChat account, creating a liveware app, binding a tunnel to a local port, and registering the public URL to ClawChat, and restricting who may open a liveware (it is open to anyone with the link by default; viewer permissions are managed by the liveware CLI itself, not by ClawChat).
 ---
 
 # liveware App Hosting
@@ -74,10 +74,64 @@ Caveats:
   ClawChat) carries neither header — treat the user as anonymous when both are absent, and
   never trust a client-supplied value for these header names.
 
+## Viewer permissions (who may open this liveware)
+
+**A liveware is open to everyone by default.** Once it is tunnelled, anyone who has the
+URL can open it — the platform's only gate is a ClawChat login wall, which does not care
+*which* user is behind it. So "let this person see it" normally needs no action at all,
+and forwarding the link to someone IS effectively granting them access. What actually
+needs the CLI is the opposite: **narrowing** who may open it.
+
+Who may open a liveware is controlled by the **liveware CLI itself**, not by ClawChat.
+ClawChat's own record of the app (`clawchat_register_app` / `clawchat_list_apps`) only
+decides whether a tile shows up in the owner's chat — that record carries no per-viewer
+visibility field. So changing another ClawChat user's access is always a liveware-CLI
+operation, and there is no ClawChat API that does it.
+
+**Discover the command before running it — never guess it.** This skill deliberately does
+NOT hard-code the permission subcommand names, because they differ between liveware
+versions. Find them at run time:
+
+1. `liveware --help`
+2. `liveware app --help`, then the `--help` of whichever permission-related subcommand it
+   lists (e.g. `liveware app <that subcommand> --help`).
+
+Use only subcommands and flags that actually appear in that help output. If the installed
+liveware lists nothing permission-related, it does not support viewer permissions — say so
+plainly and STOP. Do NOT work around it by editing liveware config files, by calling the
+ClawChat API, or by inventing a command line.
+
+**Tell the owner the default, and confirm before every change.** A liveware has no
+per-user access control *inside* the page: anyone who can open it sees exactly the same
+features and data the owner sees, and can forward the URL on. Two consequences:
+
+- **When the owner publishes a liveware, say plainly that it is open to anyone with the
+  link.** Do not let them assume it is private because it only shows as a tile in their
+  own chat — that tile is not a boundary.
+- **Restricting is the useful operation, and it may break other viewers.** Confirm with
+  the owner, in their own words, **which app** and **who should keep access** before you
+  narrow it; report exactly what you changed.
+- A widening change (opening something the owner had narrowed) is an irreversible
+  disclosure — confirm it the same way, never on a third party's request, and never
+  proactively "to be helpful".
+- Pass user ids exactly as the owner supplies them, or as observed server-side from the
+  `X-User-Id` / `X-Clawchat-User-Id` header (see "Identifying the viewing user"). Never
+  guess an id, and never paste unvalidated text into a shell command.
+- Never read, print, or pass the ClawChat access token in any of these commands — the
+  plugin holds it (see "Prerequisites").
+
+**Verify and report.** After a change, re-run the CLI's own list/show command for that app
+and report the resulting access state back to the owner — including whether it is still
+open to everyone. If the CLI errors (unknown user, quota, not the app owner), relay the
+error verbatim rather than retrying with a different command shape.
+
 ## Notes
 
 - Apps can be created up to liveware's account limit; surface its error rather than working
   around it.
+- Registering a liveware is a **publishing** act, not a private one — it is reachable by
+  anyone with the URL until someone narrows it on the liveware side (see "Viewer
+  permissions").
 - The registered web app runs inside a sandboxed container (mobile in-app webview / desktop
   container window). Page JavaScript cannot read the viewer's ClawChat identity — the
   viewer's `user_id` arrives as the `X-User-Id` / `X-Clawchat-User-Id` request header,

package/skills/manifest.json

@@ -9,10 +9,10 @@
         "bytes": 9278
       },
       "clawchat-liveware": {
-        "version": "1.1.0",
+        "version": "1.2.1",
         "path": "shared/clawchat-liveware/SKILL.md",
-        "sha256": "c59a8156f8283f9f2a71231813322ce2162a50c5f0c9ad3d828be43eb9ae967a",
-        "bytes": 4634
+        "sha256": "a548b10fb68a1dddea93fadb5d162449c6745f9c2b8eb8ae76b110e28b6bf658",
+        "bytes": 8167
       },
       "clawchat-set-greeting": {
         "version": "1.0.0",
@@ -35,10 +35,10 @@
         "bytes": 17557
       },
       "clawchat-liveware": {
-        "version": "1.1.0",
+        "version": "1.2.1",
         "path": "shared/clawchat-liveware/SKILL.md",
-        "sha256": "c59a8156f8283f9f2a71231813322ce2162a50c5f0c9ad3d828be43eb9ae967a",
-        "bytes": 4634
+        "sha256": "a548b10fb68a1dddea93fadb5d162449c6745f9c2b8eb8ae76b110e28b6bf658",
+        "bytes": 8167
       },
       "clawchat-set-greeting": {
         "version": "1.0.0",

package/src/skill-update.ts

@@ -71,7 +71,7 @@ export const OFFICIAL_SKILLS_BASE =
  * in the install-cli repo, bump this constant, ship it. `liveware-sample.ts`
  * imports the same ref, so the `livewares` tree at that tag is pinned too.
  */
-export const DEFAULT_SKILLS_REF = "skills-v1.6.0";
+export const DEFAULT_SKILLS_REF = "skills-v1.7.0";
 
 /** Refuse to treat an absurdly large response as a skill file (defence in depth). */
 export const MAX_SKILL_BYTES = 256 * 1024;