Summary

File attachments (images, documents) in historical Slack thread messages are not made available to the LLM when thread history is fetched via thread.initialHistoryLimit.

Problem to solve

When a user posts an image in a Slack thread reply and the bot is @mentioned later in the same thread, the bot fetches thread history but only receives a plain-text placeholder like [attached: screenshot.png] for any messages that contained files. The actual file content is never downloaded for historical messages — only for the triggering message and conditionally the thread root. This means the bot cannot reason about images or documents that are part of the thread's prior conversation, which is a significant limitation for workflows where visual context builds up over multiple thread replies.

Proposed solution

Two complementary approaches:

A — Automatic download during history fetch
Download attachments from thread history messages as part of the existing initialHistoryLimit history fetch, so they are available to the LLM from the start of the session without any extra interaction.

B — On-demand via agent tool
Allow the agent to fetch file content on demand when asked by the user. This requires the message tool's read action (which already supports threadId) to include file metadata in the returned message summaries, and a way for the agent to download a specific Slack file and receive it as a media attachment. Approach B is useful independently of A, since it would allow the agent to retrieve any Slack file on demand, not only ones encountered during history replay.

Alternatives considered

Users can work around the limitation by including the relevant image in the same message where they @mention the bot, but this is impractical when the image was posted earlier in the thread by someone else.

Impact

• Affected: any Slack channel or thread where images/files are shared before the bot is mentioned
• Severity: blocks workflow — bot cannot see visual context that is central to the conversation
• Frequency: common in threads that start with a screenshot, diagram, or document and escalate to a bot mention
• Consequence: users must re-upload images or work around the limitation manually

Evidence/examples

Related: PR #15447 fixed the same class of issue for multi-image messages on live inbound messages. The thread history path was not covered by that fix.