MiniMax-AI / MiniMax-AI/minimax-code

Support Lark international (larksuite.com) tenants in Feishu Bot QR-onboarding

Open
#106 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

desktop enhancement needs-triage
Dominant language
TypeScript
Stars
1.3k
Forks
141
Avg merge
2h 45m
Merged PRs (30d)
46

Description

Summary

When adding the Feishu (Lark) mobile channel through the QR-bind flow in MiniMax Code, tenants hosted on accounts.larksuite.com / open.larksuite.com (Lark international) are rejected with a hard error before onboarding completes. Only feishu.cn tenants work. Other AI agents we use (ZCode, Hermes Agent) handle both brand endpoints transparently, so this puts MiniMax Code at a disadvantage for any user whose organization is on the international Lark stack.

User-visible behaviour

  1. Open the "Bind Feishu Bot via QR" dialog in MiniMax Code.

  2. Scan the QR with the Lark mobile app while signed into an international tenant (e.g. yourcorp.larksuite.com).

  3. Approve the PersonalAgent consent on the mobile side.

  4. MiniMax Code shows a dialog with the literal message:

    Lark international tenant detected — current onboarding only supports feishu.cn

    with a "Retry" button that loops back to the same error.

Expected: the bot is bound, the runner connects, and the channel works — same as it does for feishu.cn.

Root cause (from daemon.js in current build)

The QR-onboarding pipeline is hard-wired to the Feishu (China) endpoints and refuses any tenant whose tenant_brand comes back as "lark":

  • packages/daemon/src/channel-bridge/plugins/feishu/app-registration.ts
    • requestAppRegistration() ignores options.brand and always hits https://accounts.feishu.cn/oauth/v1/app/registration (line ~117287 in the bundled daemon.js).
    • verificationUriComplete is hard-coded to https://open.feishu.cn/page/cli?user_code=... (line ~117303), even though the URL table right next to it already defines a lark entry pointing at https://open.larksuite.com.
  • packages/daemon/src/channel-bridge/plugins/feishu/auth.tsFeishuAuthAdapter.registerNewApp() calls requestAppRegistration({ brand: "feishu" }) with a hard-coded "feishu" (line ~117485).
  • FeishuAuthAdapter.completeAppRegistration() throws on result.tenantBrand === "lark" with the message Restart the registration on accounts.larksuite.com (not yet implemented) (lines ~117531-117535).
  • The HTTP route that drives the onboarding UI (POST /api/lark/onboard/start) already accepts a brand field in its request body and forwards it to reqApp({ brand }) (lines ~369654, ~369664), but the underlying requestAppRegistration ignores it, so the field is effectively dead.

The bundled URLs (ACCOUNTS_BASE, OPEN_BASE) and the comment "a follow-up will switch to accounts.larksuite.com" (line ~117515) confirm the limitation is intentional and tracked in-tree, just not implemented.

Suggested approach

A few options, ordered from smallest to largest change:

  1. Honour options.brand end-to-end. Two-line fix in app-registration.ts:

    • ACCOUNTS_BASE[options.brand ?? "feishu"] instead of ACCOUNTS_BASE.feishu.
    • OPEN_BASE[options.brand ?? "feishu"] instead of OPEN_BASE.feishu.
      Then expose a brand selector (or auto-detect from the response) in the "Bind Feishu Bot via QR" dialog so the user can pick feishu.cn vs larksuite.com.
  2. Auto-detect brand. The app-registration begin endpoint actually returns tenant info; have the UI first probe the user's logged-in identity (or read it from a config flag) and route to the matching URL set automatically — this is what ZCode / Hermes Agent appear to do.

  3. Remove the early-return on tenantBrand === "lark". Currently runOnboard() aborts the session the moment it sees "lark" (line ~369532). Once option 1 is in place, that branch can just propagate the chosen apiBase (https://open.larksuite.com) downstream into the Feishu plugin so subsequent IM calls hit the right host — apiBaseUrl is already a configurable field per the schema at line ~97307 ("Override API base URL (e.g., https://open.larksuite.com for Lark)").

Option 1 + propagating apiBase from the chosen brand is the minimum to unblock international users; option 2 is what would make MiniMax Code competitive with the agents that already handle this transparently.

Environment

  • MiniMax Code: latest stable build installed via the macOS app bundle (/Applications/MiniMax Code.app).
  • Tenant: Lark international (<org>.larksuite.com), authenticated in the Lark mobile app at scan time.
  • Repro'd on macOS 15.

Happy to test a fix or supply more details from the bundled daemon.js if useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with packages/daemon/src/channel-bridge/plugins/feishu/app-registration.ts and auth.ts, then trace POST /api/lark/onboard/start and runOnboard(). Follow how the brand and apiBase values move through QR registration. Done means larksuite.com tenants use the international endpoints, complete registration without the current rejection, and the runner connects through the bound channel.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, authentication, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.