[Bug]: feishu channel still not work

[dongxuanlb]

Summary

2026-03-01T03:02:26.804139583+00:00 WARN zeroclaw::channels: Lark/Feishu channel is configured but this build was compiled without channel-lark; skipping Lark/Feishu health check.

Affected component

channel

Severity

S1 - workflow blocked

Current behavior

config with:
[channels_config.feishu]
app_id = "some"
app_secret = "some"
allowed_users = ["*"]
mention_only = false
use_feishu = true
receive_mode = "websocket"
draft_update_interval_ms = 3000
max_draft_edits = 20

zeroclaw daemon

🦀 ZeroClaw Gateway listening on http://0.0.0.0:42617
🌐 Web Dashboard: http://0.0.0.0:42617/
POST /pair — pair a new client (X-Pairing-Code header)
POST /webhook — {"message": "your prompt"}
POST /api/chat — {"message": "...", "context": [...]} (tools-enabled, OpenClaw compat)
POST /v1/chat/completions — OpenAI-compatible (full agent loop)
GET /v1/models — list available models
GET /api/* — REST API (bearer token required)
GET /ws/chat — WebSocket agent chat
GET /health — health check
GET /metrics — Prometheus metrics
🔒 Pairing: ACTIVE (bearer token required)
Press Ctrl+C to stop.

2026-03-01T03:02:26.804139583+00:00 WARN zeroclaw::channels: Lark/Feishu channel is configured but this build was compiled without channel-lark; skipping Lark/Feishu health check.
No channels configured. Run zeroclaw onboard to set up channels.
2026-03-01T03:02:26.804321458+00:00 WARN zeroclaw::daemon: Daemon component 'channels' exited unexpectedly

Expected behavior

work with feishu

Steps to reproduce

zerao daemon

Impact

feishu not work

Logs / stack traces

ZeroClaw version

latest

Rust version

rustc 1.93.1 (01f6ddf75 2026-02-11)

Operating system

ubuntu 22.04 6.12.54-linuxkit docker

Regression?

No, first-time setup

Pre-flight checks

• I reproduced this on the latest main branch or latest release.
• I redacted secrets/tokens from logs.
• I removed personal identifiers and replaced identity-specific data with neutral placeholders.

[Shuimo03]

1. You need to check if Lark has web socket callbacks and event subscriptions configured.
2. When compiling, use cargo build --release --features channel-lark.

[dongxuanlb]

1. You need to check if Lark has web socket callbacks and event subscriptions configured.
2. When compiling, use cargo build --release --features channel-lark.

Thank you for reply.

I use the "cargo build --release --features channel-lark"

---

= note: expected values for feature are: browser-native, channel-lark, channel-matrix, default, fantoccini, hardware, landlock, memory-postgres, nusb, observability-otel, peripheral-rpi, probe, rag-pdf, rppal, runtime-wasm, sandbox-bubblewrap, sandbox-landlock, tokio-serial, wasm-tools, and whatsapp-web
= help: consider adding firecrawl as a feature in Cargo.toml
= note: see https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html for more information about checking conditional configuration

warning: zeroclaw (lib) generated 12 warnings
warning: zeroclaw (bin "zeroclaw") generated 12 warnings (12 duplicates)
Finished release profile [optimized] target(s) in 2m 31s
zerobot@6b0418f76c2d:~/zeroclaw$ zeroclaw daemon
2026-03-01T03:22:33.041692336+00:00 WARN zeroclaw::config::schema: Unknown config key ignored: "channels_config.feishu.?.mention_only". Check config.toml for typos or deprecated options.
2026-03-01T03:22:33.042009336+00:00 WARN zeroclaw::config::schema: Unknown config key ignored: "channels_config.feishu.?.use_feishu". Check config.toml for typos or deprecated options.
2026-03-01T03:22:33.043280044+00:00 INFO zeroclaw::config::schema: Config loaded path=/home/zerobot/.zeroclaw/config.toml workspace=/home/zerobot/.zeroclaw/workspace source="default" initialized=false
2026-03-01T03:22:33.043709128+00:00 INFO zeroclaw: 🧠 Starting ZeroClaw Daemon on 0.0.0.0:42617
🧠 ZeroClaw daemon started
Gateway: http://0.0.0.0:42617
Components: gateway, channels, heartbeat, scheduler
Ctrl+C to stop
2026-03-01T03:22:33.045177961+00:00 INFO zeroclaw::providers::reliable: Warming up provider connection pool provider="custom:https://api.siliconflow.cn/v1"
🦀 ZeroClaw Gateway listening on http://0.0.0.0:42617
🌐 Web Dashboard: http://0.0.0.0:42617/
POST /pair — pair a new client (X-Pairing-Code header)
POST /webhook — {"message": "your prompt"}
POST /api/chat — {"message": "...", "context": [...]} (tools-enabled, OpenClaw compat)
POST /v1/chat/completions — OpenAI-compatible (full agent loop)
GET /v1/models — list available models
GET /api/* — REST API (bearer token required)
GET /ws/chat — WebSocket agent chat
GET /health — health check
GET /metrics — Prometheus metrics
🔒 Pairing: ACTIVE (bearer token required)
Press Ctrl+C to stop.

2026-03-01T03:22:33.241252753+00:00 WARN zeroclaw::channels: Lark/Feishu channel is configured but this build was compiled without channel-lark; skipping Lark/Feishu health check.

---

in the open.feishu.cn , it seems I have to run the daemon correctly( with zeroclaw feishu client websocket connected?)

[theonlyhennygod]

Tracked fix is up in PR #2340.

Root cause identified:

1. Official Docker builds were not enabling channel-lark by default, so Feishu/Lark config was skipped at runtime.
2. Legacy Feishu keys (channels_config.feishu.mention_only / channels_config.feishu.use_feishu) produced generic unknown-key warnings that obscured migration guidance.

PR #2340 updates Docker build feature defaults, improves key diagnostics, and aligns docs.

[theonlyhennygod]

Thanks for the detailed reproduction and sorry for the setup friction here.

I completed a root-cause fix and opened PR #2350:
#2350

What was fixed:

• Added Feishu legacy-key compatibility during config load:
  • [channels_config.feishu].mention_only is now mapped to [channels_config.feishu.group_reply].mode when group_reply is not already set.
  • [channels_config.feishu].use_feishu is now treated as a redundant legacy key with a targeted migration warning instead of generic unknown-key noise.
• Improved startup diagnostics when channel-lark is missing in the running binary:
  • warning now includes the binary path and explicit commands to run the feature-enabled artifact.

Why this resolves the reported behavior:

• Your logs showed legacy Feishu keys being ignored and feature-mismatch confusion.
• The new compatibility path removes that ambiguity and preserves intent for legacy configs.
• The improved warning now makes it clear when a different/non-feature binary is being executed.

Validation highlights:

• cargo check --quiet --features channel-lark --lib
• cargo test --quiet feishu_legacy_ -- --nocapture

Also thanks @Shuimo03 for the build-feature guidance in the thread.

[theonlyhennygod]

Follow-up on #2325: I opened a superseding PR #2422 based on current main.

PR: #2422
Supersedes: #2350

Why a superseding PR was needed

• fix(feishu): improve legacy config compatibility and startup guidance #2350 had an open review concern around permissive legacy-path matching logic.
• fix(feishu): legacy config compatibility + startup guidance (supersedes #2350) #2422 keeps the compatibility/startup fixes but simplifies detection to explicit raw-TOML Feishu key presence (mention_only, use_feishu), avoiding false-positive path matching behavior.

What is included

• Feishu legacy compatibility mapping:
  • [channels_config.feishu].mention_only -> group_reply.mode when group_reply is absent
  • targeted warnings for deprecated/redundant legacy keys
• Improved startup diagnostics in channels runtime when feature/build mismatch is present
• Cleaner detection path without dependency/lockfile churn

Validation highlights

• cargo check --quiet --features channel-lark --lib ✅
• cargo test --quiet feishu_legacy_ -- --nocapture currently blocked by existing upstream lib test compile issue in src/gateway/mod.rs (AppState initializer missing bluebubbles fields), unrelated to this patch