claw-lark Patches

Re-apply custom patches to claw-lark plugin dist files after updates. Use when claw-lark plugin is updated/reinstalled and custom behaviors (requireMention f...

Security Scan

The skill's files and runtime instructions are consistent with its stated purpose (re-applying local patches to claw-lark plugin dist files); it modifies local plugin files and does not request unrelated credentials or download remote code.

Purpose & Capability

The skill is described as re-applying patches to the claw-lark plugin, and the package contains an apply-patches.sh script plus patch diffs for the plugin's dist files. All required actions (reading/writing files in the plugin dist directory, inserting BOT_OPEN_ID/BOT_NAME) align with the stated purpose.

Instruction Scope

The SKILL.md and scripts instruct the agent/user to run a local shell script that edits specific files under ~/.openclaw/extensions/claw-lark/dist/src and then restart the gateway. That is within scope for a patch applicator. Note: the script embeds BOT_OPEN_ID and BOT_NAME into the patched code (using environment variables or placeholders), and the references file documents a specific app ID and bot open_id (an author-supplied example) — the skill does not request or fetch tenant_access_token, so the user must supply correct identifiers manually.

Install Mechanism

There is no install spec or remote installer. The only executable content is the local apply-patches.sh script (and an inline Node.js patcher). No network downloads or external package installations are performed by the skill itself.

Credentials

The skill does not require credentials or special environment variables. It optionally uses BOT_OPEN_ID and BOT_NAME (non-secret identifiers) and allows CLAW_LARK_DIST to override the target path. The references file includes a concrete App ID and bot open_id (likely the author’s example) — that should not be used as-is; users must supply their own bot identifiers. No high-privilege secrets are requested.

Persistence & Privilege

The skill does not request 'always' presence and does not modify other skills' configs. It writes to the claw-lark plugin files (its intended scope). Be aware that if an agent were allowed to invoke this skill autonomously it could modify those plugin files without an explicit human prompt — that's a function of agent invocation policy, not this skill's content.

Assessment

This skill appears to do exactly what it says: modify local claw-lark dist files to reapply specific patches. Before running it: 1) Backup the target files (or the whole ~/.openclaw/extensions/claw-lark/dist/src) so you can restore if something breaks. 2) Inspect scripts/apply-patches.sh and the patch diffs in references/patch-details.md to ensure the replacements match your installed plugin version (the replacer is a string-replace, so it can silently skip or misapply if the plugin changed). 3) Set BOT_OPEN_ID and BOT_NAME to your bot's values (do not use the example bot_open_id in references); if you don't set BOT_OPEN_ID the script will insert a placeholder which will make the mention-filter behave incorrectly. 4) Run in a staging environment or when you can restart the gateway safely. 5) If you do not want the agent to autonomously modify your plugins, keep model-invocation disabled for this skill or avoid granting it autonomous execution rights. 6) If you have any doubt about owner trust (the package contains the author's sample bot ID), review every replacement the script will perform and consider applying patches manually.

claw-lark is a compiled plugin — we patch dist files directly. Every plugin update wipes these patches. This skill documents exactly what to change and provides an auto-apply script.

Quick Apply

bash scripts/apply-patches.sh

Then restart gateway: openclaw gateway restart

Patches Overview

Four files are patched:

1. channel.js — messaging.targetResolver (target ID recognition) + outbound account resolution
2. monitor.js — requireMention filtering + reply-in-thread for deliver callback
3. provider.js — reply-in-thread for sendTextMessage
4. send.js — reply-in-thread for SDK reply calls

Patch Details

0. channel.js — Target Resolution + Account Resolution (2026-02-22)

Problem 1: message(send, lark, "oc_xxx") returns "Unknown target" because claw-lark has no messaging.targetResolver.looksLikeId. The core doesn't recognize oc_/ou_/on_ as valid IDs and falls through to directory lookup which fails.

Fix: Add messaging property to larkPlugin export:

• Import looksLikeLarkId, normalizeLarkTarget from ./utils.js
• Add messaging.targetResolver.looksLikeId using existing looksLikeLarkId()
• Add messaging.normalizeTarget using existing normalizeLarkTarget()

Problem 2: outbound.sendText gets { cfg, to, accountId } from core but expects { account, recipientId }. The account object is undefined → "Cannot read properties of undefined (reading 'appId')".

Fix: All 5 outbound methods (sendText, sendMedia, downloadMedia, addReaction, removeReaction) add:

const account = args.account ?? resolveAccount(args.cfg, args.accountId ?? "default");
const recipientId = args.recipientId ?? args.to;

1. monitor.js — requireMention Filter

Location: routeMessage() function, after parseMessage(event) and the log line.

What: In group chats, skip messages that don't @mention our bot.

Key facts:

• event.message is the correct path (NOT event.event.message)
• Lark webhook message.mentions contains mention data with id.open_id
• Bot open_id: set via BOT_OPEN_ID env var when running apply-patches.sh
• All bots lack user_id (empty string) — cannot use !user_id to detect "is it me"
• @_user_N text placeholders appear for ALL @'d bots, not just ours — don't use regex match
• Fallback: if mentions array empty, check parsed.text.includes("@" + BOT_NAME) (set via BOT_NAME env var)

2. monitor.js — Reply in Thread (deliver callback)

Location: Inside dispatchReplyWithBufferedBlockDispatcher deliver callback.

What:

• Set replyToId = payload.replyToId || parsed.threadId || parsed.messageId (always have a value)
• Use client.im.message.reply() with reply_in_thread: true instead of client.im.message.create() with root_id

Key facts:

• root_id on create only associates with existing thread, does NOT create new thread
• reply_in_thread: true on reply API creates a new thread
• Works in both p2p and group chats

3. provider.js — sendTextMessage Thread Reply

Location: sendTextMessage() function.

What: When threadId is provided, use client.im.message.reply() instead of client.im.message.create().

4. send.js — reply_in_thread on SDK Reply

Location: sendMessageLark() and sendCardLark() reply branches.

What: Add reply_in_thread: true to data object in client.im.message.reply() calls.

Verification

After applying patches and restarting gateway:

1. Send a group message WITHOUT @bot → should be silently ignored
2. Send a group message WITH @bot → should reply in thread
3. Send a DM → should reply in thread
4. @ another bot → should be silently ignored

See Also

• references/patch-details.md — Full code diffs for each patch