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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants