Skip to content

feat(lark-console): Lark Open Platform developer-console adapter (8 read commands)#2008

Open
yixin-1024 wants to merge 2 commits into
jackwener:mainfrom
yixin-1024:feat/lark-console-adapter
Open

feat(lark-console): Lark Open Platform developer-console adapter (8 read commands)#2008
yixin-1024 wants to merge 2 commits into
jackwener:mainfrom
yixin-1024:feat/lark-console-adapter

Conversation

@yixin-1024

Copy link
Copy Markdown
Contributor

What

The Lark Open Platform developer console (open.larksuite.com/app) — where you create and manage custom apps/bots, scopes, versions, and credentials — has no public OpenAPI; it's driven entirely through the console UI. This adds an adapter that reads it as a CLI by calling the console's own same-origin JSON services (/developers/v1/..., /napi/...) through the logged-in Chrome session (Strategy.COOKIE).

This is squarely in OpenCLI's sweet spot: a login-gated site with no official API.

Auth

Mirrors what the console does:

  • session cookie for everything;
  • /developers/v1/... services additionally require an x-csrf-token header. The raw _csrf_token / lark_oapi_csrf_token cookies fail the check — the value the console actually sends is published as the window.csrfToken global, which consoleApi() reuses from inside the bound tab.
  • whoami / login use the cookie-only /napi/check/login endpoint.

Commands (8, read-only)

Command Description
lark-console login / whoami Console session identity (user id + tenant id)
lark-console apps Every app/bot you own or collaborate on
lark-console app <app> Basic info (name, abilities, languages, description)
lark-console secret <app> App ID + App Secret (credentials for a bot runtime)
lark-console versions <app> Version history; flags the live version (online=yes)
lark-console scopes <app> Applied API permission scopes, grouped by product area
lark-console admins <app> App admins / collaborators

<app> accepts a bare cli_… id or any console URL embedding it.

Read-only — no app creation, scope edits, or version publishing. Targets Lark; Feishu (open.feishu.cn) shares the API surface and only needs the host constant swapped (kept out of v1 so every command could be verified against a real logged-in account).

Conventions / CI

  • Typed errors throughout (AuthRequiredError / EmptyResultError / ArgumentError / CommandExecutionError); no silent fallbacks.
  • whoami / login via the shared registerSiteAuthCommands.
  • Pure formatters unit-tested (clis/lark-console/utils.test.js).
  • Doc at docs/adapters/browser/lark-console.md.
  • Gates green locally: check:silent-column-drop and check:typed-error-lint both new=0 (no baseline changes), doc-coverage --strict 168/168, tsc --noEmit clean, adapter tests pass.
  • All 8 commands verified end-to-end against a real account.

🤖 Generated with Claude Code

yixin-1024 and others added 2 commits June 24, 2026 01:19
The Lark Open Platform developer console (open.larksuite.com/app) — where you
create and manage custom apps/bots — has no public OpenAPI; it is driven entirely
through the console UI. This adapter reads it as a CLI by calling the console's own
same-origin JSON services through the logged-in Chrome session (Strategy.COOKIE).

Auth mirrors the console: the session cookie plus an `x-csrf-token` header for the
`/developers/v1/...` services. The raw `_csrf_token` / `lark_oapi_csrf_token`
cookies fail the check — the value the console actually sends is published as the
`window.csrfToken` global, which consoleApi() reuses from inside the bound tab.
The cookie-only `/napi/check/login` endpoint backs whoami/login.

8 read commands (verified against a real account):
- whoami / login  — console session identity (user id + tenant id)
- apps            — every app/bot you own or collaborate on
- app <app>       — basic info (name, abilities, languages, description)
- secret <app>    — App ID + App Secret (credentials for a bot runtime)
- versions <app>  — version history; flags the live version (online=yes)
- scopes <app>    — applied API permission scopes, grouped by product area
- admins <app>    — app admins / collaborators

Read-only: no app creation, scope edits, or version publishing. Targets Lark;
Feishu (open.feishu.cn) shares the API surface and only needs the host swapped.
Pure formatters are unit-tested; doc added under docs/adapters/browser/.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds the console's core mutation — managing an app's permission scopes — as two
write commands, guarded by --execute (mirrors the strava/garmin write convention):

- add-scope <app> <scopes> --execute     apply scope(s) to the app's draft
- remove-scope <app> <scopes> --execute  remove scope(s) from the app's draft

`<scopes>` accepts scope names (im:message) or numeric ids, comma/space-separated;
names resolve against the app's scope catalog (/developers/v1/scope/all). Both call
POST /developers/v1/scope/update with the ids in `appScopeIDs` and operation
add|del — the exact request the console's "Add permission scopes" dialog sends, so
a scope applied this way is removable the same way (the API keys off the array slot).

These edit the draft config only; scopes go live when a new version is published in
the console. No app create/delete or version publish — those are irreversible /
need tenant-admin approval, so they're intentionally left out.

Verified end-to-end against a real bot (add by name → confirm applied → remove by id
→ confirm gone; trace cleaned up). --execute guard, doc, and a splitScopes unit test
added. Local CI green: adapter tests (node+bun), silent-column-drop / typed-error-lint
(new=0), doc-coverage --strict, tsc --noEmit, docs:build.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@louie-via

Copy link
Copy Markdown

Hi @jackwener 👋 quick ping on this one too.

Why it fills a real gap: this adapter targets the Lark / Feishu Open Platform developer console (8 read-only commands). The official lark-cli does not expose developer-console operations at all — so for anyone building automation on top of Lark apps (listing apps, scopes/permissions, versions, event subscriptions, etc.), this is the missing piece that can't be done through existing tooling. 8 read commands, mergeable with no conflicts. Happy to extend or adjust the surface. Thanks for the fast review on the others! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants