English | 简体中文

Codex CLI Bridge for Lark (Feishu)

Codex CLI Bridge for Lark (Feishu) brings core Codex CLI workflows into Lark. Designed for always-on self-hosted deployment on cloud servers and VPS environments, it lets you start and continue tasks, follow live progress, respond to prompts and approvals, interrupt runs, and receive final results through native Lark messages and interactive cards. Local-host deployment is also supported.

Why this project exists

Codex CLI is most useful on a stable cloud server, VPS, or development host that keeps project tools and credentials available. Its user is not always at that host: a question may arrive during a commute, a test may need one more constraint, or a long answer may be easier to read in chat than in a terminal.

SSH, remote desktop, and terminal multiplexers help in emergencies, but they make frequent small decisions cumbersome. Forwarding chat messages into a terminal only moves text. It cannot reliably identify the active task, attach clarification to the right running turn, present a scoped approval, or recover delivery after a restart.

Moving an entire workbench into chat causes the opposite problem. Per-task dashboards, repeated progress messages, and permanent old state make a conversation unreadable. Users need a place to ask for work and receive an answer, not a control room in every direct message.

Codex CLI Bridge for Lark (Feishu) is neither a terminal copied into Lark nor a replacement for Codex. It is a lightweight, state-aware, recoverable native interaction layer between Codex CLI/app-server and Lark. It lets a normally remote task remain reachable without turning ordinary chat into a workbench.

Product design: chat first, controls when needed

The default experience is plain: send a request, add context, and receive a response. Rich cards appear only where visible structure makes an action safer or clearer.

While a task runs, a new message uses Codex's turn/steer semantics to reach that task, without creating a competing task or guessing the relationship from message text.

Status, settings, approvals, and interruption use native cards and callbacks. Where possible, a card updates in place instead of adding success receipts or replacements.

/new creates a clean session when context is too long or work needs separation; advanced history and session controls are not the center of ordinary chat.

Lightweight is a choice about what appears by default. The service retains coordination and recovery boundaries for richer controls without making them permanent clutter.

Why Lark should not become the entire Agent workbench

This engineering decision follows platform boundaries, not a claim that Lark is slow or unsuitable for development. Messages are not a transparent host file system: before a bot sends an image, audio item, video, or file, it uploads it and uses the returned resource key. Message-file uploads are limited to 30 MB, images to 10 MB; media adds format, encoding, or resolution constraints. Text bodies are limited to 150 KB, cards and rich-text messages to 30 KB.