Complete Guide: OpenClaw with Claude Code & Lark Bot
From architecture to command-line practice — a comprehensive breakdown of how OpenClaw, Claude Code, and Lark Bot work together
Tool: OpenClawTool: Claude Code
Complete Guide: OpenClaw with Claude Code and Lark Bot
This guide explains how OpenClaw, Claude Code, and a Lark bot can work together as one operating loop.
The goal is not to make one tool do everything. The goal is to let each tool handle the layer it is good at.
Roles
Component
Role
Core capability
Claude Code
Local coding agent
Reads and edits code, runs shell commands, uses Git, and handles engineering tasks
OpenClaw
Local AI gateway and channel hub
Connects Telegram, Lark, Discord, and other channels; dispatches models and tools
Lark bot
Collaboration interface
Sends and receives team messages, docs, and operational updates
Collaboration mode
The practical workflow is:
Send an instruction from Telegram or Lark.
OpenClaw receives the message.
OpenClaw can spawn Claude Code as a local subprocess through ACP.
Claude Code performs the engineering task on the machine.
OpenClaw sends the result back to the chat.
The important point is that Claude Code remains local and capable, while OpenClaw handles channel access and routing.
Binding a chat to Claude Code
To bind the current chat to Claude Code:
text
/acp spawn claude --bind here
This creates a Claude ACP session in the current chat. Messages sent after that can be forwarded directly to Claude Code, and Claude works in the configured local workspace.
Persistent threads
For larger tasks, use a persistent thread:
text
/acp spawn claude --mode persistent --thread auto
This keeps intermediate progress, results, and follow-up context in a dedicated topic instead of polluting the main chat.
One-shot execution
For short tasks:
text
/acp spawn claude --mode oneshot
This is useful for one-off work such as reviewing a pull request, generating a short report, or checking a repository state.
Common ACP commands
Command
Purpose
/acp status
Check the current ACP binding
/acp cancel
Cancel the running task
/acp close
Close the session and unbind
/acp doctor
Check ACP health
Using Claude with Lark operations
Claude Code does not directly need to own Lark tools. A clean split is:
OpenClaw handles Lark messages, documents, and bot identity.
Claude Code handles coding, debugging, and local file work.
OpenClaw takes Claude's output and sends it into Lark.
This avoids mixing channel permissions into the coding agent.
Example: engineering daily report
Bind Claude in Telegram:
text
/acp spawn claude --bind here
Ask Claude to draft the report:
text
Write a daily engineering update:- Done: fixed the login bug- In progress: refactoring the order module- Blocked: waiting for design
Ask OpenClaw to send the result to the target Lark group.
OpenClaw uses the configured bot identity to send the message.
Bot identity
Using a bot identity is operationally stable:
no personal login session expiration
predictable permission scope
suitable for scheduled or background workflows
easier to audit than user-level automation
Recommended mental model
Use Claude Code as the local engineering worker.
Use OpenClaw as the gateway and dispatcher.
Use Lark as the collaboration surface.
That split keeps the system composable without forcing one agent to own every integration.
Research on OpenClaw's native Lark integration — a complete migration path from Webhook Bridge to WebSocket long-connection, with full configuration steps
Tool: OpenClawChannel: Telegram + Lark
Why Default Workflows Belong in AGENTS.md, Not in a Skill
The question sounds like a documentation placement issue: should a complex default workflow live in AGENTS.md, or should it become a dedicated skill?
In practice, it is a question about system boundaries.
The short answer
A default workflow belongs in AGENTS.md because it is routing logic. It decides how the agent should classify a request, which knowledge source to read first, when to ask a question, and when to execute.
A skill is different. A skill is an execution module for a specific domain once the task has already been routed.
In other words:
AGENTS.md decides which path to take.
A skill explains how to walk a specific path.
Why this cannot live inside one skill
The default workflow runs before any skill is selected.
If the rule says "first decide whether a skill applies," putting that rule inside a skill creates a loop: the agent would need to invoke a skill before it knows whether to invoke a skill.
That is the wrong layer.
The default workflow should sit above all skills because it governs intake, routing, escalation, and execution discipline across every task type.
AGENTS.md as the routing layer
AGENTS.md is useful for rules that apply broadly:
how to inspect the repo before editing
how to choose between implementation, review, and research
when to ask a clarifying question
how to handle multi-step work
how to respect local project constraints
how to coordinate with specialized skills
Those rules are not tied to one domain. They shape the agent's behavior before the domain is known.
Skills as execution modules
Skills are best used for specialized workflows:
reviewing a draft article
generating a logo asset matrix
building a spreadsheet
drawing a technical architecture diagram
installing or publishing a skill
Each skill should assume the task has already been classified. Then it can provide detailed steps, scripts, templates, and checks for that domain.
The useful split
A healthy agent system keeps the layers separate:
Global behavior and routing live in AGENTS.md.
Domain-specific procedures live in skills.
Project-specific facts live in docs, decisions, learn notes, and local AGENTS.md files.
This separation keeps the agent predictable. It also makes skills easier to reuse because they do not need to carry global operating rules.
Practical rule
If a rule answers "how should the agent decide what to do next?", put it in AGENTS.md.
If a rule answers "how should the agent complete this specific class of task?", put it in a skill.
Practice Log: Multi-Agent Serial Pipeline with Cursor + Git Worktree
Core goal: Use a single prompt to trigger multiple sub-agents into an automated serial workflow, enabling parallel development across multiple tasks.
Current proposal:openspec/changes/redesign-skill-card-vertical
Automated Serial Workflow (Agent Pipeline)
Note: Do not use a SubAgent for any step that does not explicitly ask for one.
0 TASK 0: Proposal review
Model: Gemini-3.1-pro
Task: Use the openspec-review-specs skill.
Focus: Review proposal completeness, key data flows, and property/interface alignment.
1 TASK 1: Architect review
Model: Opus 4.6
Task: Review and improve the proposal from an architect's perspective. Use the neversight-skills_feed-system-architect skill.
Focus: Examine the system design, look for reuse opportunities, and make sure the solution is robust.
2 TASK 2: Implementation
Model: Opus 4.6
Task: Run /opsx/apply directly to turn the refined proposal into code.
3 TASK 3: Code review
Model: Codex-5.3 (model switch)
Task:
Run git commit to save the initial implementation.
Review the current commit strictly against the proposal.
This phase is read-only: do not modify code, so the review remains objective.
4 SubAgent 4: Auto-refinement
Model: Opus 4.6 (switch back)
Task: Ingest the review report from Agent 3, then update and fix the implementation based on the feedback.
5 SubAgent 5: Archiving
Model: Opus 4.6
Task:
Run /opsx/archive to archive the proposal status.
Run the final git commit to close the loop for this feature.
Bottleneck Review and Optimization
The current pipeline is highly automated, but the total runtime is still a bit long.
Optimization idea: The current sub-agent responsibilities are too fine-grained. A next step is to reduce granularity by merging highly cohesive tasks, such as combining architect review and implementation into one larger agent step, or combining auto-refinement and archiving. This reduces communication overhead from model switching and context passing, which should improve total execution speed.
Complete Guide: OpenClaw with Claude Code and Lark Bot
This guide explains how OpenClaw, Claude Code, and a Lark bot can work together as one operating loop.
The goal is not to make one tool do everything. The goal is to let each tool handle the layer it is good at.
Roles
Component
Role
Core capability
Claude Code
Local coding agent
Reads and edits code, runs shell commands, uses Git, and handles engineering tasks
OpenClaw
Local AI gateway and channel hub
Connects Telegram, Lark, Discord, and other channels; dispatches models and tools
Lark bot
Collaboration interface
Sends and receives team messages, docs, and operational updates
Collaboration mode
The practical workflow is:
Send an instruction from Telegram or Lark.
OpenClaw receives the message.
OpenClaw can spawn Claude Code as a local subprocess through ACP.
Claude Code performs the engineering task on the machine.
OpenClaw sends the result back to the chat.
The important point is that Claude Code remains local and capable, while OpenClaw handles channel access and routing.
Binding a chat to Claude Code
To bind the current chat to Claude Code:
text
/acp spawn claude --bind here
This creates a Claude ACP session in the current chat. Messages sent after that can be forwarded directly to Claude Code, and Claude works in the configured local workspace.
Persistent threads
For larger tasks, use a persistent thread:
text
/acp spawn claude --mode persistent --thread auto
This keeps intermediate progress, results, and follow-up context in a dedicated topic instead of polluting the main chat.
One-shot execution
For short tasks:
text
/acp spawn claude --mode oneshot
This is useful for one-off work such as reviewing a pull request, generating a short report, or checking a repository state.
Common ACP commands
Command
Purpose
/acp status
Check the current ACP binding
/acp cancel
Cancel the running task
/acp close
Close the session and unbind
/acp doctor
Check ACP health
Using Claude with Lark operations
Claude Code does not directly need to own Lark tools. A clean split is:
OpenClaw handles Lark messages, documents, and bot identity.
Claude Code handles coding, debugging, and local file work.
OpenClaw takes Claude's output and sends it into Lark.
This avoids mixing channel permissions into the coding agent.
Example: engineering daily report
Bind Claude in Telegram:
text
/acp spawn claude --bind here
Ask Claude to draft the report:
text
Write a daily engineering update:- Done: fixed the login bug- In progress: refactoring the order module- Blocked: waiting for design
Ask OpenClaw to send the result to the target Lark group.
OpenClaw uses the configured bot identity to send the message.
Bot identity
Using a bot identity is operationally stable:
no personal login session expiration
predictable permission scope
suitable for scheduled or background workflows
easier to audit than user-level automation
Recommended mental model
Use Claude Code as the local engineering worker.
Use OpenClaw as the gateway and dispatcher.
Use Lark as the collaboration surface.
That split keeps the system composable without forcing one agent to own every integration.
OpenClaw + Telegram + Lark Integration Research Report
Research date: 2026-03-13
Goal: Run OpenClaw with both Telegram and Lark so the same gateway can receive messages, dispatch agents, and send operational updates across channels.
Current setup
The current OpenClaw environment already has Telegram running normally. Lark is connected through a webhook bridge rather than the native OpenClaw integration.
Channel
Status
Notes
Telegram
Running
Multiple bots are configured, with direct-message and group policies
The bridge receives Lark events, forwards them to OpenClaw, handles group reply rules, and performs message deduplication.
This works, but it has costs:
extra service to maintain
Cloudflare Tunnel requirement
more moving parts during outages
limited access to native OpenClaw Lark features
Native Lark integration
OpenClaw can integrate with Lark directly through a long-lived WebSocket connection. That removes the public webhook endpoint and reduces the deployment surface.
Native integration can support:
direct messages
group messages with bot mentions
interactive card messages
bot message sending
media file handling
Migration plan
Step 1: Create or update the Lark app
Create a Lark enterprise app, enable bot capability, and get the App ID and App Secret.
Step 2: Configure permissions
The app should include permissions for receiving and sending IM messages, reading message resources, and accessing files if the workflow needs media handling.
OpenClaw becomes the single channel hub. Claude Code or other local agents can then be launched behind it through ACP.
Recommendation
Move Lark from webhook bridge mode to native integration.
The migration reduces maintenance cost, avoids public tunnel dependency, and makes the Lark channel match the Telegram channel more closely in operational behavior.
Suggested priority:
Switch Lark to native integration.
Re-check Telegram DM and group policies.
Add advanced Lark capabilities such as file upload and user identification only after the basic channel is stable.