slackapi / slackapi/slack-skills-plugin

slack_read_channel returns an empty body for some bot messages that have no attachment (post-#24 fix)

Open
#150 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
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 and response_format: "detailed"): empty body
  • slack_read_thread with the same message_ts: parent returned with an empty body, plus No thread messsages [sic]
  • slack_search_public: does not surface the message
Steps to reproduce
  1. 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_channel with a limit that covers them.
  2. Compare what the tool returns with what the Slack UI shows.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.