[Bug] approval approvals get uses wrong /detail endpoint and rejects bot identity

Summary

In lark-cli v1.0.78, approval approvals get is generated as a user-only command and sends the request to:

GET /open-apis/approval/v4/approvals/{approval_code}/detail

However, the official “Get approval definition” OpenAPI uses:

GET /open-apis/approval/v4/approvals/{approval_code}

and requires a tenant access token. In a real request, the CLI-generated user-identity call returns 2200 Internal Error.

Calling the official endpoint directly with a tenant access token reaches the API successfully and returns the normal actionable permission error 60009 no approval definition permission when the app has not been granted data access to that approval definition. This suggests the CLI metadata has both an incorrect path and an incorrect supported identity.

Environment

• lark-cli: v1.0.78 (also reproduced on v1.0.69)
• OS: macOS
• Brand: Feishu

Steps to reproduce

1. Inspect the generated request

lark-cli approval approvals get   --approval-code TEST_APPROVAL_CODE   --as user   --dry-run

Actual generated request:

{
  "method": "GET",
  "url": "/open-apis/approval/v4/approvals/TEST_APPROVAL_CODE/detail",
  "identity": "user"
}

2. Try the tenant/bot identity

lark-cli approval approvals get   --approval-code TEST_APPROVAL_CODE   --as bot   --dry-run

Actual result:

--as bot is not supported, this command only supports: user

3. Execute with user identity

With a real approval code, the CLI call returns:

{
  "code": 2200,
  "msg": "Internal Error"
}

4. Compare with the native OpenAPI

curl -H "Authorization: Bearer $TENANT_ACCESS_TOKEN"   "https://open.feishu.cn/open-apis/approval/v4/approvals/TEST_APPROVAL_CODE"

The native request reaches the correct API. For an app without approval-definition data authorization, it returns the expected 60009 no approval definition permission instead of the generic 2200 error.

Expected behavior

• approval approvals get should use /open-apis/approval/v4/approvals/{approval_code} without the /detail suffix.
• The command should support bot/tenant identity and use a tenant access token, matching the official API.
• Permission problems should surface the API's actionable error (for example 60009), rather than a generic 2200 Internal Error caused by the wrong request metadata.

Related

Related to #780, which reports broken approval user-identity metadata/scopes. This issue adds a concrete wrong endpoint and bot-identity rejection for approval approvals get.

Start with the implementation or generated metadata for the approval approvals get command and reproduce its --dry-run request. Compare the command's path and supported identity with the official Get approval definition request described here. Done means the command uses the expected endpoint and accepts tenant/bot identity, with tests or dry-run output covering both changes.