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
-
Open the "Bind Feishu Bot via QR" dialog in MiniMax Code.
-
Scan the QR with the Lark mobile app while signed into an international tenant (e.g. yourcorp.larksuite.com).
-
Approve the PersonalAgent consent on the mobile side.
-
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.ts → FeishuAuthAdapter.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:
-
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.
-
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.
-
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.
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. Onlyfeishu.cntenants 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
Open the "Bind Feishu Bot via QR" dialog in MiniMax Code.
Scan the QR with the Lark mobile app while signed into an international tenant (e.g.
yourcorp.larksuite.com).Approve the PersonalAgent consent on the mobile side.
MiniMax Code shows a dialog with the literal message:
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.jsin current build)The QR-onboarding pipeline is hard-wired to the Feishu (China) endpoints and refuses any tenant whose
tenant_brandcomes back as"lark":packages/daemon/src/channel-bridge/plugins/feishu/app-registration.tsrequestAppRegistration()ignoresoptions.brandand always hitshttps://accounts.feishu.cn/oauth/v1/app/registration(line ~117287 in the bundleddaemon.js).verificationUriCompleteis hard-coded tohttps://open.feishu.cn/page/cli?user_code=...(line ~117303), even though the URL table right next to it already defines alarkentry pointing athttps://open.larksuite.com.packages/daemon/src/channel-bridge/plugins/feishu/auth.ts→FeishuAuthAdapter.registerNewApp()callsrequestAppRegistration({ brand: "feishu" })with a hard-coded"feishu"(line ~117485).FeishuAuthAdapter.completeAppRegistration()throws onresult.tenantBrand === "lark"with the messageRestart the registration on accounts.larksuite.com (not yet implemented)(lines ~117531-117535).POST /api/lark/onboard/start) already accepts abrandfield in its request body and forwards it toreqApp({ brand })(lines ~369654, ~369664), but the underlyingrequestAppRegistrationignores it, so the field is effectively dead.The bundled URLs (
ACCOUNTS_BASE,OPEN_BASE) and the comment "a follow-up will switch toaccounts.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:
Honour
options.brandend-to-end. Two-line fix inapp-registration.ts:ACCOUNTS_BASE[options.brand ?? "feishu"]instead ofACCOUNTS_BASE.feishu.OPEN_BASE[options.brand ?? "feishu"]instead ofOPEN_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.cnvslarksuite.com.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.
Remove the early-return on
tenantBrand === "lark". CurrentlyrunOnboard()aborts the session the moment it sees"lark"(line ~369532). Once option 1 is in place, that branch can just propagate the chosenapiBase(https://open.larksuite.com) downstream into the Feishu plugin so subsequent IM calls hit the right host —apiBaseUrlis 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
apiBasefrom 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
/Applications/MiniMax Code.app).<org>.larksuite.com), authenticated in the Lark mobile app at scan time.Happy to test a fix or supply more details from the bundled
daemon.jsif useful.