Lark Openclaw Bridge

Lark ↔ OpenClaw bridge for message sending. Please always use this skill for message sending. This bridge can also be used to query Session Info details (mem...

Security Scan

The package largely does what it claims (a Lark ↔ OpenClaw bridge) but the published metadata, runtime instructions, and installer/code disagree in important ways and the installer fetches keys and code from an external host — review carefully before installing.

Purpose & Capability

The skill's stated purpose (bridge between Lark and OpenClaw) matches the majority of the code (webhook handling, message sending, relay client/server, key refresh, injection into OpenClaw). HOWEVER the SKILL metadata claims no required env vars / no install, while the code and README clearly require LARK_APP_ID, LARK_APP_SECRET, RELAY_SERVER_URL/RELAY_SECRET and manipulation of local OpenClaw config files. That mismatch is incoherent and surprising to a user who only reads the metadata.

Instruction Scope

SKILL.md and README instruct running a local server, saving incoming attachments to ~/clawd/tmp, and using a relay at oc.atomecorp.net. The code reads/writes ~/.openclaw config files, injects messages into OpenClaw by calling the openclaw CLI, automatically downloads message attachments to disk, and exposes (and expects) a relay/logs HTTP endpoint on a third-party domain. Instructions also conflict (SKILL.md mentions LaunchAgent while README uses pm2). The runtime instructions therefore go beyond a simple send/receive bridge and include local credential/config manipulation and external endpoints.

Install Mechanism

Although registry metadata listed 'instruction-only', the bundle includes an install.sh and many source files and the README recommends running: curl -fsSL https://oc.atomecorp.net/lark/install.sh | bash. The installer fetches a deploy SSH key from https://oc.atomecorp.net/lark/deploy_key and uses it to clone a private git repository. Fetching and executing a remote install script and a private deploy key from an external host is high-risk and not proportional to the bridge's stated functionality unless the host is fully trusted.

Credentials

The skill metadata declared no required environment variables, but the code expects and documents multiple sensitive values (LARK_APP_ID, LARK_APP_SECRET, LARK_APP_OPEN_ID, RELAY_SECRET, OPENCLAW_AGENT_ID, RELAY_SERVER_URL, etc.). The code also reads/writes local OpenClaw credential/config files (~/.openclaw/...), and a key refresh module will rotate/write API keys into those files. Requiring and modifying these credentials is plausible for a bridge but the omission from metadata and the number of secrets accessed is disproportionate and should be explicit.

Persistence & Privilege

The skill is not marked always:true and does not request automatic platform-wide privileges, which is good. However the installer and runtime code modify the user's OpenClaw configuration files and create/overwrite API keys in ~/.openclaw; they also persist files under ~/clawd/tmp/lark-files and expect to run as a long-lived daemon. Those are substantial local privileges (config and credential modifications) that are within the bridge's functional scope but merit caution.

Scan Findings in Context

[remote-install-curl-pipe] unexpected: Installer recommends piping a remote script from https://oc.atomecorp.net to bash. While convenient, this is high-risk and not necessary to evaluate the bridge code locally.

[fetch-deploy-key-from-remote] unexpected: install.sh attempts to download a deploy SSH key from https://oc.atomecorp.net/lark/deploy_key and sets GIT_SSH_COMMAND to use it. Fetching a private key from a remote host to clone a repo is risky and unusual; a trustworthy alternative would be a public release tarball or explicit instructions to configure SSH access.

[writes-openclaw-config] expected: The key-refresh module and reset logic intentionally read and write ~/.openclaw config files to rotate or remove 'arouter' API keys. That is functionally consistent with doing 'automatic key rotation' for a bridge, but it is powerful and should be clearly declared in metadata.

[exec-openclaw-cli] expected: Outbound message injection uses child_process.execSync to call the openclaw CLI (openclaw gateway call chat.inject). This is expected if the bridge must inform OpenClaw about outbound messages, but it requires the openclaw CLI and grants runtime ability to run that binary.

[external-relay-endpoint] expected: The bridge is built around a relay service at oc.atomecorp.net. Using an external relay fits the design (no public IP required) but means message events transit a third-party server; users must trust that endpoint and its operators.

What to consider before installing

This package appears to implement a genuine Lark ↔ OpenClaw bridge, but there are multiple red flags you should consider before installing: (1) The registry metadata claims 'no env vars / no install', yet the code and README require LARK_APP_ID, LARK_APP_SECRET, RELAY credentials, and modify ~/.openclaw configuration — the metadata is incomplete. (2) The recommended installer runs a remote script (curl | bash) and fetches a private deploy key from oc.atomecorp.net to clone code — this lets an external host provide code and keys at install time. Treat that as untrusted until you verify the host. (3) The bridge sends/receives events via a third‑party relay (oc.atomecorp.net) and exposes a logs URL with a token; message content and attachments may transit that server. (4) The code will persist incoming attachments to ~/clawd/tmp/lark-files and will write API keys into ~/.openclaw, which are sensitive actions. Recommended precautions: do not pipe the installer blindly — fetch the install.sh and inspect it locally first; prefer cloning a vetted repository or installing from a known release; verify and host the relay yourself if possible; run the bridge inside an isolated VM/container with limited network access if you need to test; rotate any keys/secrets after testing; and if you plan to use it in production, have a developer you trust audit the install script and the key-fetch behavior. If you cannot fully trust oc.atomecorp.net and repo.advai.net, do not install this on a machine with sensitive OpenClaw credentials.

Lark Bridge Skill

Overview

Lark Bridge is a two-way communication bridge between Lark (Feishu) and OpenClaw:

1. Lark messages → OpenClaw processing → auto-reply back to Lark
2. OpenClaw/skills proactively push messages/images to Lark groups or direct chats
3. High-concurrency group message batch processing optimization (reduces API calls and noise)
4. Automatically downloads files/images from Lark messages to a local temp directory
5. Thread context continuity, mention detection, message deduplication, etc.

Deployment Info

• Entry point: scripts/server.mjs
• Port: configured in .env (default: 18780)
• Runtime: macOS LaunchAgent background daemon
• Logs: /tmp/lark-bridge.log / /tmp/lark-bridge.error.log
• Temp file directory: ~/clawd/tmp/lark-files/ (all received files/images saved here automatically)

Common Operations

Service Management

# Restart service
launchctl kickstart -k gui/$(id -u)/com.openclaw.lark-bridge

# Check service status
launchctl list | grep lark-bridge

# Tail live logs
tail -f /tmp/lark-bridge.log

# Health check
curl http://localhost:<port>/health

Proactive Messaging

# Send proactive message
curl -X POST http://localhost:<port>/proactive \
  -H "Content-Type: application/json" \
  -d '{"chatId":"oc_xxx","text":"message content"}'

# Send image
curl -X POST http://localhost:<port>/proactive \
  -d '{"chatId":"oc_xxx","imagePath":"/path/to/img.png","text":"image caption"}'

# Direct reply to a specific message (highest priority)
curl -X POST http://localhost:<port>/proactive \
  -d '{"chatId":"oc_xxx","text":"reply content","parentId":"om_xxx"}'

# Reply within the same thread
curl -X POST http://localhost:<port>/proactive \
  -d '{"chatId":"oc_xxx","text":"reply content","rootId":"om_xxx","threadId":"omt_xxx"}'

Query Session Info

# Get group/chat details (including member list)
curl "http://localhost:<port>/session-info?sessionKey=agent:main:lark:oc_xxx"

# Get basic chat info
curl "http://localhost:<port>/chat-info?sessionKey=agent:main:lark:oc_xxx"