Problem
When using slck messages thread <channel> <ts> --output json, the JSON output includes type, user, text, ts, thread_ts, and reactions fields — but omits the files field even when messages contain file attachments (images, documents, etc.).
The Slack API's conversations.replies endpoint returns full files metadata (id, name, mimetype, size, url_private, thumbnails, etc.), but this data is stripped from the CLI output.
Expected behavior
When a message contains file attachments, the JSON output should include the files array with at least:
idnamemimetype / filetypesizeurl_privatepermalink
Why this matters
Automated consumers of thread data currently have no way to tell that a message included an attachment. A message like "see the screenshot below" appears identical to a plain text message, losing important context.
Scope
This likely applies to other message-returning commands too (messages history, search messages, etc.) — but messages thread is the most common place where attachments appear in context.
Problem
When using
slck messages thread <channel> <ts> --output json, the JSON output includestype,user,text,ts,thread_ts, andreactionsfields — but omits thefilesfield even when messages contain file attachments (images, documents, etc.).The Slack API's
conversations.repliesendpoint returns fullfilesmetadata (id, name, mimetype, size, url_private, thumbnails, etc.), but this data is stripped from the CLI output.Expected behavior
When a message contains file attachments, the JSON output should include the
filesarray with at least:idnamemimetype/filetypesizeurl_privatepermalinkWhy this matters
Automated consumers of thread data currently have no way to tell that a message included an attachment. A message like "see the screenshot below" appears identical to a plain text message, losing important context.
Scope
This likely applies to other message-returning commands too (
messages history,search messages, etc.) — butmessages threadis the most common place where attachments appear in context.