slackapi / slackapi/slack-skills-plugin
slack_read_channel returns an empty body for some bot messages that have no attachment (post-#24 fix)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 132
- Forks
- 34
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 16
Description
Plugin version
slack plugin 1.3.0 from the claude-plugins-official marketplace, talking to the Slack-hosted MCP server at https://mcp.slack.com/mcp.
Client
Claude Code
Operating System
macOS (client); the behavior comes from the hosted MCP server.
Description
Some bot messages come back from slack_read_channel with sender and timestamp but a completely empty body. Other messages from the same bot, in the same channel, in the same minute return their full text.
This is not #24 / #45 (legacy attachments[].text, fixed server-side on 2026-08-25): attachment content from another app in the same channel renders correctly for us. It is also not #126: the affected message shows no colored sidebar in the Slack UI, so its content is not inside an attachment, and the body comes back empty rather than as a [no preview available] placeholder.
The message renders normally in the Slack UI: a @mention line followed by roughly ten bullet lines with emoji and links.
The content cannot be recovered through the plugin:
slack_read_channel(default andresponse_format: "detailed"): empty bodyslack_read_threadwith the samemessage_ts: parent returned with an empty body, plusNo thread messsages[sic]slack_search_public: does not surface the message
Steps to reproduce
- In a channel where an app posts several long Block Kit messages within the same minute (about a dozen posts, each 1-20 bullet lines), call
slack_read_channelwith a limit that covers them. - Compare what the tool returns with what the Slack UI shows.
- Some messages come back with an empty body. Which ones are affected varies from day to day. The blank ones are not the longest, and they have no attachment (no colored sidebar).
Across two days we saw three messages return an empty body while neighbouring messages from the same bot, one second apart, returned their full text.
Expected behavior
The same text the Slack UI shows, as happens for the neighbouring messages.
Actual behavior
=== Message from <bot> (<bot user id>) at <timestamp> ===
Message TS: <ts>
Body is empty. The same message copied from Slack with "Copy message" starts:
@<mention>
• :emoji: <Name>: 1 new users — <Name>
• :emoji: <Name>: 5 new users — <Name>, <Name>, ...
Impact
It fails silently. A client reading the channel sees no content for those messages rather than an error, so downstream work is built on an incomplete set with no indication that anything was dropped. We only noticed because a person spotted that a message they could see in Slack was missing from the output.
Related
- #24 and #45: same symptom, different cause (legacy attachments), fixed server-side on 2026-08-25. A comment on #24 describes an attachment + Block Kit variant that was never split into its own issue.
- #126: content nested in
attachments[].blocks[], still open, but returns a placeholder rather than an empty body.
Contributor guide
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 with the plugin's slack_read_channel entry point and reproduce the issue against the hosted Slack MCP server at https://mcp.slack.com/mcp using the described Block Kit bot messages. Compare the tool output with Slack and the related slack_read_thread and slack_search_public results; done means affected messages return their visible text instead of an empty body.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100