// the find
zarazhangrui/lark-coding-agent-bridge
Bot that bridges Feishu/Lark messenger with a local Claude Code or Codex CLI. Streaming cards, per-chat sessions, multiple workspaces
A Node.js bridge that lets you drive a local Claude Code or Codex CLI session from Feishu/Lark chat — DM or @-mention the bot and it streams agent replies and tool calls into a live chat card, with per-chat sessions and multiple project workspaces. Built for people already living in Feishu/Lark who want to kick off and monitor coding-agent runs from their phone instead of a terminal, and want the bot running as a real background service, not a demo script.
The access-control model is actually well thought out: three tiers (users/chats/admins), private by default, the app creator can never lock themselves out, and unauthorized strangers get silent non-replies instead of a 'permission denied' that would confirm the bot exists. Profiles are properly isolated — separate credentials, sessions, workspaces, logs, and even a per-profile LARKSUITE_CLI_CONFIG_DIR — so you can run Claude and Codex as two genuinely independent bots rather than sharing state. It ships real ops tooling: launchd/systemd/Windows Task Scheduler daemon wiring per profile, plus an idle watchdog that kills a frozen agent subprocess instead of leaving the chat card stuck forever. Telemetry is an opt-in adapter interface that no-ops on any failure (missing module, throwing adapter), so a bad integration can't take the bot down.
New profiles default both defaultAccess and maxAccess to 'full', which maps to bypassPermissions/danger-full-access — out of the box, a chat message can trigger arbitrary file writes and shell-level tool calls with no sandbox; the working-directory check only rejects obviously dangerous roots like '/', it isn't a real containment boundary. The 'owner' identity is derived automatically from whoever owns the Feishu app, with no explicit confirmation step, so an app transfer or misconfiguration silently hands over the privileged identity. The README itself flags a sharp edge: installing the daemon through npx instead of a global install means the launchd/systemd/Task Scheduler entry points at an npm temp cache path that can vanish on cache cleanup, breaking the background service. There's a lot of surface area for what's conceptually a relay — card rendering, three daemon backends, session catalogs, workspace store, meeting orchestration, lark-cli identity policy — which raises the bar for anyone wanting to audit or extend it confidently.