[Feature Request] Add im +messages-export for copy-friendly chat message export
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 17.3k
- Forks
- 1.4k
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 105
Description
Problem
Current lark-cli im +messages-mget can batch fetch messages as structured JSON, but there is no copy-friendly export command for selected chat messages.
In real Feishu/Lark workflows, users often need to select several chat messages and share them with designers, producers, PMs, or external collaborators as readable text or Markdown. The desktop client can display these messages, but reliably copying multiple messages is difficult, especially when messages include rich post content, replies/quotes, images, files, sender names, timestamps, and original message links.
Current workaround
Today the practical workflow is:
- Use
im +chat-messages-listorim +messages-searchto locate message IDs. - Use
im +messages-mget --message-ids "om_xxx,om_yyy"to batch fetch full message JSON. - Write ad-hoc parsing logic to convert the JSON into human-readable Markdown/text.
This works for agents and scripts, but every workflow has to re-implement the export formatting.
Proposal
Add a shortcut:
lark-cli im +messages-export
The goal is to export selected messages into copy-paste friendly Markdown/text while preserving enough structure for traceability.
Suggested input modes
Fetch by explicit message IDs:
lark-cli im +messages-export --message-ids "om_xxx,om_yyy,om_zzz"
Fetch by chat and time window:
lark-cli im +messages-export \
--chat-id oc_xxx \
--start 2026-04-08T00:00:00+08:00 \
--end 2026-04-10T23:59:59+08:00
Optionally, search then export:
lark-cli im +messages-export --chat-id oc_xxx --query "keyword"
Suggested output formats
--format markdown
--format text
--format json
markdown and text should be optimized for direct copy/paste into chat, docs, and reports. json should preserve the structured result for scripts.
Expected exported fields
For each message, include when available:
- sender display name
- send time
- message text / post content
- reply or quote context
- image, file, link placeholders or downloaded paths when requested
message_app_linkchat_idor chat name if availablemessage_idfor traceability
Example Markdown output shape:
### 2026-04-09 21:20 | Alice
Replying to Bob:
Please use this version.
The fabric on the body should be changed to silk, or removed directly because it looks uncomfortable.
Add some shiny colored scales to the tail so the tail color has more variation.
Attachments:
- image: img_xxx
Source:
- message_id: om_xxx
- link: https://...
Non-goals
- This does not need to simulate Feishu/Lark desktop client multi-select UI.
- OCR for images is not required.
- Merge-forward is useful, but it is not the same as exporting messages as copyable text.
Why existing commands are not enough
+messages-mget is useful for structured JSON, but users still need a readable "copy this to someone" format. A dedicated export shortcut would reduce repeated ad-hoc parsing in agents and scripts.
Environment where this was observed
lark-cli version 1.0.40im +messages-mgetexists and supports batch fetching by comma-separated message IDs.im messages forward,im messages merge_forward, andim threads forwardexist, but they are forwarding workflows, not copy-friendly text export workflows.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the existing im +messages-mget, im messages forward, im messages merge_forward, and im threads forward command entry points to understand message retrieval and output conventions. Define the supported input and format scope before implementation; done means selected messages can be exported as readable Markdown or text with the requested traceability fields, while JSON remains structured.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100