You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every device-flow login succeeds and stores an access token whose granted scope includes offline_access, but the token response never contains a refresh_token. The CLI prints [WARN] device-flow: no refresh_token in response, sets refreshExpiresAt == expiresAt, and silent renewal is therefore impossible — the user has to re-scan a QR code every ~2 hours.
App: created via the CLI app registration flow (/oauth/v1/app/registration), app_id cli_a8cd685509bd1013
Developer console shows the offline_access permission (持续访问已授权的数据, user identity) as 已开通/enabled
What was ruled out before filing
Missing scope in the request — the CLI always auto-appends offline_access to the device authorization scope (internal/auth/device_flow.go:72), and one of the logins below additionally passed an explicit --scope offline_access.
Console permission not enabled — the console shows offline_access as enabled for user identity.
Server not granting the scope — after each login, auth status shows the stored scope ending with offline_access. The stored scope is taken from the token response's scope field (cmd/auth/login.go stores result.Token.Scope), so the server itself reports offline_access as granted.
[lark-cli] device-flow: token response received
[lark-cli] [WARN] device-flow: no refresh_token in response
and resulted in refreshExpiresAt exactly equal to expiresAt (grantedAt + 2h).
Questions
Under what server-side conditions does /open-apis/authen/v2/oauth/token (grant_type urn:ietf:params:oauth:grant-type:device_code) omit refresh_token while still including offline_access in the returned scope?
Does enabling offline_access in the console require publishing a new app version before the token endpoint starts issuing refresh tokens? If so, could the console/docs/CLI surface this more clearly?
Could this be specific to apps created through the CLI app-registration flow?
Happy to provide the full ~/.lark-cli/logs/auth-*.log privately if useful.
Describe the bug
Every device-flow login succeeds and stores an access token whose granted
scopeincludesoffline_access, but the token response never contains arefresh_token. The CLI prints[WARN] device-flow: no refresh_token in response, setsrefreshExpiresAt == expiresAt, and silent renewal is therefore impossible — the user has to re-scan a QR code every ~2 hours.Environment
@larksuite/cli), macOS arm64 (Darwin 25.5.0)feishu/oauth/v1/app/registration), app_idcli_a8cd685509bd1013offline_accesspermission (持续访问已授权的数据, user identity) as 已开通/enabledWhat was ruled out before filing
offline_accessto the device authorization scope (internal/auth/device_flow.go:72), and one of the logins below additionally passed an explicit--scope offline_access.offline_accessas enabled for user identity.auth statusshows the stored scope ending withoffline_access. The stored scope is taken from the token response'sscopefield (cmd/auth/login.gostoresresult.Token.Scope), so the server itself reportsoffline_accessas granted.Docs say
refresh_token"仅在请求成功且用户授予 offline_access 权限时返回" — both conditions appear satisfied here, yet the field is absent.Sanitized log lines (all three token exchanges today)
Each of these logins printed:
and resulted in
refreshExpiresAtexactly equal toexpiresAt(grantedAt + 2h).Questions
/open-apis/authen/v2/oauth/token(grant_typeurn:ietf:params:oauth:grant-type:device_code) omitrefresh_tokenwhile still includingoffline_accessin the returnedscope?offline_accessin the console require publishing a new app version before the token endpoint starts issuing refresh tokens? If so, could the console/docs/CLI surface this more clearly?Happy to provide the full
~/.lark-cli/logs/auth-*.logprivately if useful.