How to Use OpenClaw with Feishu or Lark

Feishu and Lark are team collaboration platforms, and OpenClaw's Feishu channel is documented as production-ready for bot DMs and group chats. WebSocket is the default mode, with webhook mode optional. The simplest setup is not hand-editing credentials; it is the channel login wizard. The docs require OpenClaw 2026.4.25 or above, then use a QR-code flow to create a bot automatically from the Feishu/Lark mobile app.

Run the wizard

Start with openclaw channels login --channel feishu. Scan the QR code with the Feishu or Lark mobile app and let the wizard create the bot. After setup completes, restart the gateway with openclaw gateway restart. That restart applies the new channel configuration. If you are on an older OpenClaw version, upgrade first instead of trying to force a channel config that expects newer plugin behavior.

Choose DM policy

Direct messages are controlled by dmPolicy. The docs list pairing for unknown users receiving a pairing code, allowlist for only users listed in allowFrom, open for all users, and disabled for no DMs. For a company bot, start with pairing or allowlist. Approve requests with openclaw pairing list feishu and openclaw pairing approve feishu <CODE>. Open DM mode is convenient, but it is rarely the safest first production setting.

Control group behavior

Group chats have a separate groupPolicy. open responds in all groups, allowlist responds only in configured groups, and disabled turns group messages off. The default is allowlist. Mention gating is controlled by requireMention, which defaults true. Per-group overrides can tune behavior for a specific chat id. Broadcast-only @all and @_all are not bot mentions, which prevents a general team announcement from accidentally waking the assistant.

Use group allowlists first

The docs show groupAllowFrom values that look like oc_xxx. Start with one internal test group, require mention, and restrict senders if the room is busy. Only after the bot behaves well should you widen the policy. Feishu groups can have operational chatter, documents, calendars, and team norms; OpenClaw should enter that space as a controlled teammate, not as a bot that replies to everything.

Runbook

Record the OpenClaw version, bot creation method, DM policy, group policy, require-mention setting, allowed group ids, and pairing commands. Send one DM, one allowed group mention, and one group message without a mention to confirm the gates. The OpenClaw Playbook's channel discipline applies cleanly here: default-deny group reach, approve humans intentionally, and keep enough notes that the next operator can understand why Feishu behaves the way it does.

Prefer one controlled pilot group

Feishu group policy is flexible enough to create noisy failures if you skip the pilot phase. Start with one group, one owner, mention required, and a small sender set. Let the team use the bot for a few real requests, then inspect whether replies were helpful and whether any messages should have been ignored. Only then broaden group access. Feishu and Lark workspaces can be fast-moving, so a bot that behaves well in a quiet test channel may still be too chatty in an operations room. The allowlist and mention controls exist so you can widen gradually.

Final verification

Before calling How to Use OpenClaw with Feishu or Lark finished, perform one direct test, one failure test, and one rollback check. The direct test proves the happy path works. The failure test proves the documented guardrail is real, not just assumed. The rollback check tells the next operator how to undo the change without improvising. Save those notes beside the channel, node, or gateway config you changed. OpenClaw gets powerful when agents can act, but it stays trustworthy when every new surface has a small, repeatable verification habit attached to it.