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

package/dist/src/friend-request-turn.js

@@ -0,0 +1,83 @@
+/**
+ * Synthetic reasoning-turn builder for `friend.request` notify.signal events.
+ *
+ * When the server fires a `friend.request` signal the runtime dispatches one
+ * deduped synthetic `message.send` envelope so the agent can reason about the
+ * pending request. The prompt text varies by the current "friend.add" permission
+ * policy state: a deny policy yields a decline/inform prompt; ask or allow
+ * yields a prompt that instructs the agent to review the request via the
+ * `clawchat_list_friend_requests` tool.
+ */
+import { EVENT } from "./protocol-types.js";
+/**
+ * Returns canned prompt text for a friend-request reasoning turn based on the
+ * current "friend.add" permission policy state.
+ *
+ * - `deny`  → inform the agent it should decline; no accept instruction.
+ * - `ask` / `allow` → instruct the agent to review the pending request.
+ *
+ * The requester's user id is embedded so the agent does not go looking up the
+ * synthetic sender ("clawchat-friend-request" is not a real user).
+ */
+export function friendRequestPromptFor(state, requesterUserId) {
+    const arrived = requesterUserId
+        ? `A new friend request has arrived from user ${requesterUserId}.`
+        : "A new friend request has arrived.";
+    if (state === "deny") {
+        return [
+            arrived,
+            "Your current friend-add policy is set to deny.",
+            "Do not add this contact.",
+            "You may inform the requester that you cannot add them at this time.",
+        ].join(" ");
+    }
+    return [
+        arrived,
+        "Please review the pending request by calling `clawchat_list_friend_requests`",
+        "and decide whether to accept it.",
+    ].join(" ");
+}
+/**
+ * Builds a synthetic `message.send` envelope that triggers one agent reasoning
+ * turn for a pending friend request. The envelope shape mirrors the
+ * activation-bootstrap envelope; it targets the owner's direct conversation so
+ * the agent has context about who it is reasoning for.
+ */
+export function buildFriendRequestEnvelope(params) {
+    const { account, state, entityId, ownerConversationId } = params;
+    const text = friendRequestPromptFor(state, entityId);
+    const now = Date.now();
+    // Fall back to ownerUserId only when no activation conversation is recorded:
+    // the turn still runs (the agent can act via tools, e.g. accept the request),
+    // but its in-chat replies will not be deliverable until activation records
+    // the owner conversation.
+    return {
+        version: "2",
+        event: EVENT.MESSAGE_SEND,
+        trace_id: `clawchat-plugin-openclaw-friend-request-${entityId}-${now}`,
+        emitted_at: now,
+        chat_id: ownerConversationId ?? account.ownerUserId,
+        chat_type: "direct",
+        to: { id: account.userId, type: "direct" },
+        sender: {
+            id: "clawchat-friend-request",
+            type: "direct",
+            nick_name: "ClawChat",
+        },
+        payload: {
+            message_id: `clawchat-plugin-openclaw-friend-request-${entityId}-${now}`,
+            message_mode: "normal",
+            message: {
+                body: { fragments: [{ kind: "text", text }] },
+                context: { mentions: [], reply: null },
+                streaming: {
+                    status: "static",
+                    sequence: 0,
+                    mutation_policy: "sealed",
+                    started_at: null,
+                    completed_at: null,
+                },
+            },
+        },
+    };
+}

package/dist/src/runtime.js

@@ -2352,7 +2352,6 @@ export async function startOpenclawClawlingGateway(params) {
     };
     const dispatchTurnToAgent = async (turn) => {
         const rt = runtime.channel;
-        const storePath = rt.session.resolveStorePath(cfg.session?.store);
         const routeCfg = withClawChatSessionScope(cfg);
         const route = rt.routing.resolveAgentRoute({
             cfg: routeCfg,
@@ -2360,6 +2359,13 @@ export async function startOpenclawClawlingGateway(params) {
             accountId,
             peer: turn.peer,
         });
+        // OpenClaw >=2026.8 (roster-only refactor, openclaw#112678) throws
+        // SessionStoreAgentIdRequiredError when `session.store` is unset and no agentId is
+        // supplied — that killed every inbound turn. Older hosts already accepted
+        // `opts.agentId` and merely defaulted it to "main", so passing the routed id is
+        // correct on the whole supported range and resolves to the same path for a
+        // single-agent roster. Must stay below resolveAgentRoute: it owns `agentId`.
+        const storePath = rt.session.resolveStorePath(cfg.session?.store, { agentId: route.agentId });
         const memoryRoot = resolveClawChatMemoryRoot(runtime, cfg, route.agentId);
         const body = rt.reply.formatAgentEnvelope({
             channel: "Clawling Chat",

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.9.1-1",
   "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/runtime.ts

@@ -2818,7 +2818,6 @@ export async function startOpenclawClawlingGateway(params: StartGatewayParams):
 
   const dispatchTurnToAgent = async (turn: IngestTurnParams): Promise<IngestTurnResult> => {
     const rt = runtime.channel;
-    const storePath = rt.session.resolveStorePath(cfg.session?.store);
     const routeCfg = withClawChatSessionScope(cfg);
     const route = rt.routing.resolveAgentRoute({
       cfg: routeCfg,
@@ -2826,6 +2825,13 @@ export async function startOpenclawClawlingGateway(params: StartGatewayParams):
       accountId,
       peer: turn.peer,
     });
+    // OpenClaw >=2026.8 (roster-only refactor, openclaw#112678) throws
+    // SessionStoreAgentIdRequiredError when `session.store` is unset and no agentId is
+    // supplied — that killed every inbound turn. Older hosts already accepted
+    // `opts.agentId` and merely defaulted it to "main", so passing the routed id is
+    // correct on the whole supported range and resolves to the same path for a
+    // single-agent roster. Must stay below resolveAgentRoute: it owns `agentId`.
+    const storePath = rt.session.resolveStorePath(cfg.session?.store, { agentId: route.agentId });
     const memoryRoot = resolveClawChatMemoryRoot(runtime, cfg, route.agentId);
     const body = rt.reply.formatAgentEnvelope({
       channel: "Clawling Chat",

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;