Windows: `--params` JSON parsing fails for `im messages read_users` (and other non-empty params calls)

[GannonSun]

Summary

On Windows, lark-cli appears to support im messages read_users, but any call that passes a non-empty JSON object to --params fails in CLI parsing.

The Feishu OpenAPI itself works correctly. The same request succeeds in the official API debugger.

Environment

• OS: Windows
• Shell: PowerShell
• CLI version: lark-cli 1.0.0

What works

• lark-cli im messages read_users --help
• lark-cli schema im.messages.read_users
• Feishu OpenAPI debugger successfully calls:
  • GET /open-apis/im/v1/messages/{message_id}/read_users
  • with user_id_type=open_id

What fails

This command is expected to work, but fails with JSON parsing error:

lark-cli im messages read_users --as bot --params '{"message_id":"om_x100b53a771492ca8b4ca3ca7535d2d0","user_id_type":"open_id"}' --format json

Actual result:

{
  "ok": false,
  "identity": "bot",
  "error": {
    "type": "validation",
    "message": "--params invalid JSON format"
  }
}

I also observed similar behavior on Windows for other commands when --params is a non-empty JSON object.

For example, even a simple dry-run can fail:

lark-cli api GET /open-apis/calendar/v4/calendars --as user --dry-run --params '{"foo":"bar"}'

Actual result:

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "validation",
    "message": "--params invalid format, expected JSON object"
  }
}

Additional notes

• Empty params like --params '{}' may pass in some cases.
• Non-empty JSON consistently fails in my Windows environment.
• I also tried PowerShell stop-parsing (--%) and different quoting styles, but the result was the same.

Expected behavior

--params should accept valid JSON objects on Windows the same way it does conceptually on other platforms, especially for generated commands like:

lark-cli im messages read_users --as bot --params '{"message_id":"...","user_id_type":"open_id"}'

Why I believe this is a CLI issue

• The API itself is valid and returns success in the official Feishu API debugger.
• The CLI exposes the command in help and schema.
• The failure happens before the API request is successfully formed, at parameter parsing/validation stage.

If there is a Windows-specific correct way to pass non-empty JSON into --params, please document it. Otherwise this looks like a CLI parsing bug on Windows.

[xxlxxs]

I hit the same issue on Windows + PowerShell (lark-cli 1.0.0), and it seems broader than --params
only.

I also saw similar failures with:

• --data for write APIs (for example comment-related calls could fail with --data invalid format, expected JSON object
  )
• doc comment posting with complex JSON bodies like reply_elements / mention_user
• multi-line --markdown arguments in docs +update
  (reported success, but only the first line was written in my case)

In all these cases, the underlying API worked once I bypassed normal Windows shell quoting and called the CLI entrypoint from a local Node helper with an explicit argument array.

So this looks like a broader Windows CLI argument-parsing issue, not just a single
--params
bug.

Potential fixes:

• support --params @file.json / --data @file.json
  reliably

add Windows-focused tests for JSON and multiline arguments

document a Windows-safe invocation pattern if one already exists

[zjplab]

English

I hit the same Windows + PowerShell issue on lark-cli 1.0.1, with a different command that blocked a real migration workflow.

Environment:

• OS: Windows
• Shell: PowerShell
• CLI: lark-cli 1.0.1

Repro:

lark-cli wiki spaces get_node --params '{"token":"<redacted_wiki_node_token>"}' --format json --as user

Actual result:

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "validation",
    "message": "--params invalid JSON format"
  }
}

I also tried assigning the JSON to a PowerShell variable first and then passing --params $json; same result.

Why this mattered in practice:

• I was migrating a Notion knowledge base into a Lark wiki.
• docs +create and docs +update worked fine on the same machine/account.
• But wiki spaces get_node could not be called through --params, which made it harder to inspect target wiki node metadata and automate the import cleanly.

So this is not limited to im messages read_users; wiki spaces get_node is affected too on Windows PowerShell.

中文

我在 Windows + PowerShell 上也遇到了同样的问题，CLI 版本是 lark-cli 1.0.1。这次触发问题的是另一个命令，而且它直接阻塞了一个真实的迁移流程。

环境：

• 操作系统：Windows
• Shell：PowerShell
• CLI：lark-cli 1.0.1

复现命令：

lark-cli wiki spaces get_node --params '{"token":"<redacted_wiki_node_token>"}' --format json --as user

实际结果：

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "validation",
    "message": "--params invalid JSON format"
  }
}

我也试过先把 JSON 赋值给 PowerShell 变量，再传给 --params $json，结果相同。

这个问题在实际中的影响：

• 我当时在把 Notion 知识库迁移到 Lark Wiki。
• 同一台机器、同一账号下，docs +create 和 docs +update 都可以正常工作。
• 但 wiki spaces get_node 无法通过 --params 调用，导致很难读取目标 wiki 节点元数据，也很难把导入流程自动化做好。

所以这个问题不只是 im messages read_users，wiki spaces get_node 在 Windows PowerShell 下也会受影响。