larksuite/cli: the official Lark and Feishu CLI, built for humans and AI Agents

What larksuite/cli is for, and who should reach for it

larksuite/cli is the official command line tool for the Lark and Feishu open platform, maintained by the larksuite team and published under the MIT license. The README frames it as built for humans and AI Agents, and the feature table backs that up: Calendar, Messenger, Docs, Drive, Markdown, Base, Sheets, Slides, Tasks, Wiki, Contact, Mail, Meetings, Attendance, Approval, OKR and Apps, plus a standalone meegle-cli for project work that installs separately.

The problem it solves is not really "call an API from a shell." Anyone can curl the open platform. The problem is that the Lark API surface is wide, each domain has its own object model, and wiring authentication, pagination and output formatting by hand for each one is repetitive work that produces brittle scripts. lark-cli collapses that into a three-layer command system the README describes as Shortcuts (human and AI friendly), API Commands (platform-synced), and Raw API (full coverage).

The audience is narrower than the feature list suggests. If your team does not use Lark or Feishu, nothing here applies to you. If it does, the tool is aimed at two groups: individual developers who want their calendar, docs and mail reachable from a terminal, and teams embedding the CLI inside an agent or internal platform through the extension/ packages.

The three-layer command system and how a call actually flows

The architecture is layered rather than flat, and the layer you pick determines how much the tool does for you. Shortcuts are the top layer: opinionated, human-readable commands such as lark-cli calendar +agenda that map to a common task rather than a single endpoint. API Commands sit in the middle and are described as platform-synced, meaning they track the open platform's own API shape. Raw API is the bottom layer and exists for full coverage when no shortcut or synced command fits.

Underneath, the Go module depends on github.com/larksuite/oapi-sdk-go/v3, so the CLI is a client of the official SDK rather than a reimplementation of the HTTP surface. Flag parsing comes from spf13/cobra and pflag, output filtering from itchyny/gojq, and diffing from sergi/go-diff, which hints at the write and patch paths for Docs and Markdown files. Credentials are stored through zalando/go-keyring, which is the OS-native keychain the README refers to under security.

The repository also carries a sidecar/ directory and three main entry points (main.go, main_authsidecar.go, main_noauthsidecar.go), a build-time split that lets the same codebase produce a binary with or without the authentication sidecar. That is a real architectural decision, and it is the kind of thing the README does not explain in prose.

Installing larksuite/cli and making a first calendar call

The README lists two install paths. The npm route is the recommended one and needs only Node.js, since package.json declares engines.node as >=16 and ships a postinstall script that fetches the platform binary. The source route needs Go v1.23 or later and Python 3.

The npm install runs through npx and drops you into a guided setup:

npx @larksuite/cli@latest install

If you prefer to build from source, the Makefile exposes an install target that builds with trimpath and injects a version and date through ldflags. Note the second command in that path: the README marks the CLI skill install as required, not optional.

git clone https://github.com/larksuite/cli.git
cd cli
make install
npx skills add larksuite/cli -y -g

With the binary in place, configuration is a one-time interactive step, then login. The --recommend flag is documented as auto-selecting commonly used scopes, which is convenient but worth revisiting if your workload is unusual.

lark-cli config init
lark-cli auth login --recommend
lark-cli calendar +agenda

The first two commands are interactive; expect a browser step for authentication. The third is a Shortcut-layer command, so it prints a formatted agenda rather than a raw API response. If you get an authorization error instead of a calendar, the scopes selected by --recommend are the first thing to check.

Platform coverage is constrained by package.json: os lists darwin, linux and win32, and cpu lists x64, arm64 and riscv64. Anything outside that matrix is not supported by the published package.

Agent Skills: the part that is genuinely different

Most CLIs are documented as a command reference and left at that. lark-cli ships a skills/ directory and a skill-template/, and the README counts 26 AI Agent Skills, with the headline bullets disagreeing slightly (one says 24 structured Skills, another says 26). Skills are structured descriptions an agent can consume to operate Lark without the user writing integration code first. The repository also has isolated-skills/ and an affordance/ directory, plus content_embed.go and content_embed_affordance_test.go at the top level, which suggests skill content is embedded into the binary at build time rather than fetched.

That embedded-content approach is the interesting bet. It means a skill definition can be tested alongside the command it describes, and the Makefile has a live-skills-test target and a quality-gate target that emits a command manifest, a command index and a facts file. A project that generates machine-readable manifests of its own commands is optimizing for agent consumption in a way that a plain --help dump does not.

The cost is coupling. Skills are versioned with the CLI, so an agent pinned to an older binary gets older skill text, and the README does not describe a compatibility policy between skill versions and CLI versions. If you build an agent on top of this, pin the CLI version and re-read the skill files on upgrade.

Where lark-cli is the wrong tool

Three cases stand out.

First, anything outside Lark or Feishu. The tool is a client for one platform's open API, and the domain list is a map of that platform, not a general integration framework. If your workflow spans Slack, Google Workspace and Jira, lark-cli covers exactly one of those.

Second, server-side automation that needs database, Vault or config-center credentials. The default credential path is the OS keychain via go-keyring, which is right for a laptop and wrong for a container. The README points enterprise embedders at the extension/ packages and a wrapper main instead, describing that route as extending without modifying CLI source. That is a different integration effort than npm install, and teams that assume the quick start scales to a fleet will discover this late.

Third, anyone who needs a frozen command surface. The CLI moves fast: releases v1.0.90, v1.0.91 and v1.0.92 landed within four days of each other in late August 2026, and the last push to main was on 2026-08-28. The README also carries a security and risk warnings section it tells you to read before use, which is not a section a project adds for decoration. Restricted command surfaces are explicitly framed as an enterprise concern, not a default.

How it compares to calling the open platform directly

The honest alternative is the official Go SDK that lark-cli itself depends on, github.com/larksuite/oapi-sdk-go/v3. Using the SDK directly gives you typed request and response structs, compile-time checking, and no subprocess boundary. You own authentication, token refresh and pagination, but you also control them completely, and you can embed the client in a long-running service without shelling out.

The difference in approach is abstraction versus control. lark-cli gives you a stable command surface, shortcuts that encode common tasks, structured output designed for agent consumption, and credential storage handled for you. The SDK gives you the same API reach with none of that, plus the ability to shape retries, concurrency and error handling to your own service's needs.

A rough rule: if a human or an agent is going to type the operation, lark-cli is the shorter path. If a service is going to execute it thousands of times a day, the SDK is the better fit, and the CLI's three-layer command model becomes overhead you did not ask for. The meegle-cli project is a separate install for Meegle work items, so project management is not covered by this binary.

Licence, maintenance and the upgrade cost you are signing up for

The licence is MIT, declared in both the repository and package.json. MIT is permissive: it allows commercial and closed-source use with attribution and without a copyleft obligation. That is a statement about the licence text, not legal advice, and the copyright line in the Makefile names Lark Technologies Pte. Ltd. If you redistribute a modified binary, read the LICENSE and .licenserc.yaml in the repository rather than assuming the one-line summary covers your case.

Maintenance is active by any reasonable reading. The last push to main was on 2026-08-28, the repository is not archived, and three patch releases shipped in the final week of August 2026. The version in package.json (1.0.95) is ahead of the newest listed release tag (v1.0.92), which is normal for a repository that publishes the binary through npm and tags the Go releases separately.

The upgrade cost is real, though. The npm package pins only @clack/prompts as a runtime dependency and downloads the platform binary in postinstall, so an upgrade is a binary swap rather than a dependency resolution exercise. But the CLI surface, the embedded skills and the command manifest all move together. Scripts that parse Shortcut output are the most exposed, because the shortcut layer is the one the project is free to reshape. The middle API Commands layer is described as platform-synced, which makes it the more stable surface to build against if you want fewer surprises.

Editorial conclusion

Adopt larksuite/cli if you already live in Lark or Feishu and want calendar, Docs, Base and Sheets operations scriptable from a terminal or driven by an AI Agent without hand-writing OAuth plumbing. Skip it if your work is not on the Lark platform, or if you need a command surface locked down before you have read the security section and the extension/ packages. Before rollout, verify three things: that the scopes you actually need survive auth login --recommend, that your target platform is covered by the package.json os and cpu lists, and that your team accepts OS keychain storage for credentials.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes