Lark CLI v1.0.26 & v1.0.27: Clearer Auth Errors, Message Deep Links, and an Enterprise Install Fix

Two releases in two days — v1.0.26 on May 8, v1.0.27 on May 9. Neither is a major overhaul, but both chip away at real friction points: a long-standing auth error that told you nothing useful, message outputs that couldn't deep-link back to Lark, and an installer that broke on locked-down Windows machines. Here is what changed and why it matters.

Message outputs now include app links

When you send or query messages through lark im, the output previously gave you the message ID and content — useful for chaining into more automation, but not much help if you wanted to point a human to that specific conversation in the Lark app.

v1.0.26 adds message_app_link to message outputs. It is a direct deep link that opens the message in the Lark desktop or mobile app.

A concrete use case: your automation sends daily digests to a team channel. Now you can capture the message_app_link and embed it in an external notification — email, webhook, another chat — so recipients can jump directly into the Lark conversation without hunting for it.

Auth errors now name the missing scope

Lark's OAuth model requires apps to declare specific scopes upfront. When a command fails because the app hasn't been granted the right scope, the old error was frustratingly vague — you knew something was wrong, but not what to fix.

v1.0.26 changes this. Missing-scope errors now include the exact scope name and a next step:

Teams managing multiple apps or AI agents — each with its own scope configuration — will feel this immediately. The debug loop of cross-referencing vague errors against the API documentation is gone.

lark-channel as a config bind source

v1.0.27 extends the config system with a new bind source type: lark-channel. Configuration values can now be sourced directly from a Lark channel.

In practice, this means you can maintain config state inside Lark itself — a pinned bot post, a structured message, a channel-specific entry — and have your CLI workflows read it dynamically. For teams that already use Lark as their operational hub, this removes a whole category of config-sync overhead. There is no external config file to keep in sync; the source of truth lives where the team already works.

Enterprise Windows install fix

This one is quiet but significant for enterprise environments. Many company IT policies use Group Policy to restrict or disable PowerShell script execution. The Lark CLI installer previously relied on PowerShell in a way that failed under those constraints — meaning developers on managed Windows machines simply couldn't install the tool.

v1.0.27 reworks the installation path to handle Group Policy restrictions gracefully. If your team has been hitting install errors on corporate Windows machines, this release unblocks it.

Other changes

A few smaller items worth noting:

• Cleaner base error output (v1.0.26): Bitable command errors used to surface raw internal detail that was rarely useful. Output is now trimmed to the actionable parts.
• Whiteboard +update reclassified as write risk (v1.0.26): If you run Lark CLI in a risk-gated environment, whiteboard update operations now correctly require write-level approval.
• Task member ID types clarified in docs (v1.0.27): The reference documentation for task member IDs is now more precise, reducing guesswork around which ID type to use in task operations.

Upgrade

Full changelog: github.com/larksuite/cli