LangBot 4.11 Pluginization: WeChat, Feishu, and DingTalk Connect to Claude Code and Codex

From Terminal to Group Chat: A New Entry Point for AI Coding Assistants

Teams are already using Claude Code and Codex on local machines to work with repositories, shells, and MCP servers, but when colleagues want to invoke the same capabilities directly from WeCom, Feishu, or DingTalk group chats, they have been constrained by the terminal environment. LangBot 4.11 solves this pain point through Runner pluginization, allowing external CLI agents to be installed and configured like ordinary plugins and bound to different chat platform pipelines.

According to official documentation and code repository analysis, although version 4.10 already included built-in message platform adapters such as openclaw_weixin, lark, and dingtalk, the processing side still had nine built-in Runners hardcoded in the src/langbot/pkg/provider/runners/ directory. To integrate Claude Code, you either had to modify LangBot source code or wrap the CLI in an HTTP service outside the bot. 4.11 completely flips this design: Runners become plugins, and the platform is only responsible for event sources.

Architecture Changes: Runner Pluginization and the Adapter Layer

Built-in Runners Removed

In version 4.11.0, the src/langbot/pkg/provider/runners/ directory no longer exists at all, whereas version 4.10.11 still had ten files under that directory. The provider/ directory now retains only modelmgr/, session/, and tools/. This means all Runners must be provided via plugins. At runtime, installed plugin Runners are reported through the LIST_RUNNERS protocol, and the host program caches them in the RunnerRegistry and generates IDs in the form plugin:author/plugin_name/runner_name.

The plugin manifest is the core contract, containing fields such as id, name, label, description, capabilities, permissions, config_schema, and metadata. Among these, capabilities is a typed boolean model used for UI and resource projection, not a permission grant; permissions is the upper bound of access permissions and is intersected with the binding policy. The officially provided Runner IDs include plugin:langbot-team/ClaudeCodeAgent/default and plugin:langbot-team/CodexAgent/default.

Adapter Layer Separated

4.11 adds a src/langbot/pkg/platform/adapters/ directory, split into twelve packages, each containing manifest.yaml, adapter.py, and event_converter.py. For example, the Feishu adapter's manifest declares kind: MessagePlatformAdapter. However, the inbound file manifest has not changed: from 4.10.11 to 4.11.0, all 22 files under src/langbot/pkg/platform/sources/ were modified, with none added or deleted. That is, 4.11 does not introduce new message platforms; instead, the adapter layer and event bindings determine whether a platform is available. The Runner itself does not determine platform support scope.

Hands-on Deployment: Dual Containers and Four-Step Configuration

Runner plugins execute in a separate plugin runtime container, so two containers are required: the core container and the runtime container. Below are Docker commands for local demonstration (replace network and mount paths for production):

docker network create lang7-411
docker run -d --name lang7-411-core --network lang7-411 -e BOX__ENABLED=false \
  -p 15400:5300 -v "$PWD/deploy/411/data:/app/data" rockchin/langbot:v4.11.0
docker run -d --name lang7-411-runtime --network lang7-411 --network-alias langbot_plugin_runtime \
  -v "$PWD/deploy/411/data/plugins:/app/data/plugins" \
  rockchin/langbot:v4.11.0 uv run --no-sync -m langbot_plugin.cli.__init__ rt

The administrator account is initially admin@langbot.local, with a password that is a local demonstration value and must be replaced.

Step 1: Install the plugin from the marketplace. In the UI, go to Extensions → Extension Marketplace, or call POST /api/v1/plugins/install/marketplace via the CLI, passing {plugin_author, plugin_name} and receiving {task_id}. The installation record will be marked install_source=marketplace. The article uses langbot-team/LocalAgent as an example; the Claude Code and Codex plugins go through the same entry point, with repositories located at Runner/claude-code-agent and Runner/codex-agent in langbot-plugins.

Step 2: Confirm plugin placement. Plugin artifacts are not in the mounted plugins/ directory; instead, they are located inside the runtime container at /app/data/plugin-runtime/artifacts/sha256/<digest>/code/, containing manifest.yaml, main.py, pkg/, components/, and CERTIFICATION.md. The host-mounted plugins/ directory remains empty. You can verify this in three ways: via the API (GET /api/v1/plugins returns an array containing the plugin), via the database (artifact_digest, runtime_revision, install_source, and enabled fields in the plugin_settings table), and via logs (Mounting plugin ... → Initializing Runner component: default → Component default initialized).

Step 3: Select a Runner in the pipeline. In the pipeline editor, open AI capabilities, find the stage card labeled "Run mode", and select the full Runner ID from the dropdown, for example plugin:langbot-team/ClaudeCodeAgent/default. The configuration is stored in ai.runner.id and ai.runner_config[<runner_id>], and previous settings are retained when switching Runners. For LocalAgent, for example, the configuration shows timeout: 300 and max-tool-iterations: 100. Claude Code and Codex settings come from their respective READMEs: command defaults to claude and codex respectively, timeout defaults to 300 seconds and 1800 seconds, and there are also workspace, ssh-target, mcp-servers-json, and others.

Step 4: Connect a chat platform as the event source. Connect a WeCom, Feishu, or DingTalk adapter. When an event arrives, it is routed to a pipeline through event binding, and the selected Runner performs the processing. One bot can correspond to multiple pipelines, and each pipeline can freely choose a different Runner.

Verification and Limitations: Details to Watch Out For

You can verify a successful installation at three levels: the plugin list returned by the API includes the target plugin and enabled is true; the database plugin_settings table persists the digest and revision number; ls inside the runtime container shows the aforementioned files while the host plugins/ is empty; in the pipeline, ai.runner.id must begin with plugin:, and ai.runner_config stores an object keyed by that ID. Finally, send a real message and confirm the reply comes from the installed Runner.

The following are the limitations and caveats explicitly listed in the official documentation:

• The platform is only an event source. Whether a platform is supported depends on the adapter and event bindings, not the Runner. The support matrix in 01-event-system.md is a preliminary assessment.
• Marketplace installation requires network egress. Plugin packages are pulled from {space_url}/api/v1/marketplace/plugins/download/...; installation from GitHub or a local archive is recorded as github or local.
• Artifacts are content-addressed. The marketplace-side digest may not equal the local digest and must be compared with plugin_settings.artifact_digest. The two LocalAgent 0.2.1 digests observed in the article were different.
• External CLI Runners have permissive default permissions. ClaudeCodeAgent's dangerously-skip-permissions defaults to true; setting it to false restores Claude Code's own checks, and LangBot currently has no interactive approval flow. CodexAgent defaults to approval-policy=never and sandbox-mode=danger-full-access. Use only in trusted workspaces.
• Interaction is not suspended waiting. Both CLI Runners convert requests such as ask_user_question into interaction.requested, rendered as a card by the adapter; the CLI stops, and after the user answers, a new run starts and resumes the same session.
• The Harness path is an MVP. The protocol documentation states that the external harness runner is currently an MVP/development path, not a release-grade security boundary or a complete Docker deployment solution.
• Authentication fields may be inconsistent. The article observed that install_info._certification showed verification: "invalid" and certificate_id: null, while the marketplace reported certificate_status: "issued". Do not assume local verification passed just because a plugin is listed in the marketplace.

Summary and Next Steps

In 4.11, Runners are no longer built into LangBot; instead, they are installed from the marketplace, configured in the application, and selected per pipeline. The platform is responsible for delivering events, and the Runner determines how to process them—whether it is a local CLI agent (Claude Code, Codex, ACP) or a service-based Runner such as Dify, Coze, n8n, Langflow, or DeerFlow.

Key references include the pinned migration document pipeline-migration-config-map.zh-CN.md (which lists the minimum Runner plugin versions required by the migrator) and the v4.11.0 release page. If the instance is upgraded from 4.10, how old configurations fall into the new form is the subject of another article; migration touches ai.runner.runner, ai.runner.id, and ai.runner_config simultaneously. For hosted environments, consider the Cloud solution separately (https://space.langbot.app).

One-line Summary

LangBot 4.11 turns Runners into plugins, enabling Claude Code, Codex, and other CLI agents to be invoked from group chats.

Paragraph Summary

LangBot 4.11 refactors how AI coding assistants are integrated through Runner pluginization. Previously, Runners were hardcoded in the host code, and integrating Claude Code or Codex required modifying source code or wrapping the CLI with HTTP; 4.11 removes the built-in Runner directory, requiring all Runners to be installed as plugins from the marketplace and registered with IDs in the form plugin:author/plugin_name/runner_name. The platform adapter layer is separated and only responsible for event sources; whether a chat platform is supported is determined by adapters and event bindings, independent of the Runner. Deployment requires two containers: the core container and the plugin runtime container. Configuration consists of four steps: marketplace installation, confirming placement, selecting a Runner in the pipeline, and connecting WeCom/Feishu/DingTalk. The article also warns that external CLI Runners have permissive default permissions and plugin authentication fields may be inconsistent, so use only in trusted workspaces.