Cannot upload approval attachment with user identity — /approval/v4/files/upload rejects user_access_token

Summary

When running lark-cli in a UAT-only (user identity) build, it is impossible to upload attachments for approval instances via the API. The approval file upload endpoint /open-apis/approval/v4/files/upload rejects user_access_token, so any workflow that needs to create an approval instance with an attachmentV2 widget cannot be completed end-to-end through the CLI.

Environment

• lark-cli version: v1.0.88 (also checked latest v1.0.89, no relevant changes)
• Build type: UAT-only (--as bot is rejected with --as bot is not permitted in this build (UAT-only))
• OS: macOS
• Command path: lark-cli api POST /open-apis/approval/v4/files/upload

Reproduction

1. Attempt to upload a file as an approval attachment with user identity:

lark-cli api POST /open-apis/approval/v4/files/upload \
  --as user \
  --file "file=./report.pdf" \
  --params '{"name":"report.pdf","parent_type":"approval"}'

2. The server returns:

{
  "code": 99991668,
  "msg": "user access token not support"
}

3. Since the build is UAT-only, switching to --as bot is also rejected:

--as bot is not permitted in this build (UAT-only)

4. Without a valid file code, creating an approval instance with a required attachmentV2 widget fails with validate form error 控件值不合法或者为空.

Root Cause

The Feishu/Lark Open Platform endpoint /approval/v4/files/upload only accepts tenant_access_token (bot identity), not user_access_token (user identity). This is an API-level limitation, not a CLI bug. However, the impact on CLI users is significant because:

• Many agent/automation environments (including the official UAT-only build) only have user identity available.
• The lark-approval skill documentation explicitly states that attachment file codes must be provided by the user and cannot be obtained through the CLI.
• This forces users to manually create approval instances in the Feishu client whenever an attachment is required, breaking automation workflows.

Expected Behavior

One or more of the following would resolve this:

1. CLI-level workaround: Provide a documented alternative path to obtain an approval attachment file code with user identity (e.g., via drive/v1/medias/upload_all with a specific parent_type, if the approval API accepts drive media tokens).
2. Shortcut command: Add an approval +upload-attachment shortcut that handles the identity requirement transparently (or clearly documents that bot identity is required).
3. Documentation: Explicitly document this limitation in the lark-approval skill and CLI help, including the error code 99991668 and the recommended workaround (manual creation in the Feishu client).
4. Upstream advocacy: Advocate to the Feishu Open Platform team to support user_access_token for the approval file upload endpoint, consistent with how IM file uploads already support user identity (see v1.0.13 changelog).

Actual Behavior

• Approval attachment upload fails with user access token not support (code 99991668) when using user identity.
• Bot identity is unavailable in UAT-only builds.
• No CLI shortcut exists for approval attachment uploads (unlike Base attachments, Task attachments, and IM file uploads, which all have dedicated shortcuts).
• The limitation is not clearly documented in the approval skill references.

Workaround

Manually create the approval instance in the Feishu/Lark desktop or web client and upload the attachment through the UI. This breaks automation but is the only reliable path when only user identity is available.

Related

• Issue #729 (approval attachment filename preservation) — related but distinct; that issue assumes bot identity is available.
• PR #730 (fix: preserve filenames for file uploads)
• v1.0.13: IM file upload supports user identity — demonstrates that user-identity file uploads are feasible for other domains.

Start with the lark-cli api POST /open-apis/approval/v4/files/upload path and the lark-approval skill references. Confirm the user-token error and compare the documented upload options, then define whether the result is a CLI workaround, shortcut, or explicit limitation documentation; completion should leave user-identity workflows with a documented, reliable outcome.