Documentation for msteams plugin states:

If you need images/files in channels or want to fetch message history, you must enable Microsoft Graph permissions and grant admin consent.

1. In Entra ID (Azure AD) App Registration, add Microsoft Graph Application permissions:
- ChannelMessage.Read.All (channel attachments + history)
- Chat.Read.All or ChatMessage.Read.All (group chats)
2. Grant admin consent for the tenant.
3. Bump the Teams app manifest version, re-upload, and reinstall the app in Teams.
4. Fully quit and relaunch Teams to clear cached app metadata.

After taking these steps, the issue is not resolved.

For content generated by OpenClaw and sent to a Teams user as an attachment, the attached file is saved in a directory named OpenClawShared within the document library of the SharePoint site specified in the openclaw.json config file by channels.msteams.sharePointSiteId. OpenClaw-to-user attachments work as expected with this setting in place. Note that this setting is relevant only for outbound messages.

Attachments sent in the other direction, Teams user-to-OpenClaw, do not work. In this case, attachments are uploaded to the Team associated SharePoint site into a folder matching the name of the Teams channel. This functionality is controlled by Microsoft. The message payload delivered by the Teams framework does not include any reference to the attached image (Microsoft design decision). One caveat applies - if content is pasted into the message, such as an image, that content will be delivered as part of the message payload, allowing OpenClaw to process it.

The consensus on how to handle this situation so that OpenClaw can retrieve attachments is to grant the proper Microsoft Graph permissions to the Azure (or Teams-Managed) bot. OpenClaw can then query MS Graph for each message/reply to get the full message context, including any attachments. OpenClaw currently fails to do this however.

In order to properly query MS Graph, OpenClaw needs to construct a query string consisting of these fields:

/teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies/{reply-id}

It also needs to be able to distinguish between a top-level message and a reply in a thread.

Take this example conversation:
Hi (top-level message from user to bot, id: 1780421017340)
Hello, how are you? (reply 1 from bot to user, id 1780457714560)
Describe the attached image file (reply 2 from user to bot with attachment, id: 1780422288076)

In this case all replies have their own MessageId but share a common parentMessageId. Querying MS Graph for a top-level message can be done like this:

/teams/f7e52f3d-2be8-4cb0-91a5-b709ca51754c/channels/19:[email protected]/messages/1780421017340

While replies have their own MessageId, querying a reply in the same manner will fail:

/teams/f7e52f3d-2be8-4cb0-91a5-b709ca51754c/channels/19:[email protected]/messages/1780422288076

Querying a reply must reference the parent message and use the replies field:

/teams/f7e52f3d-2be8-4cb0-91a5-b709ca51754c/channels/19:[email protected]/messages/1780421017340/replies/1780422288076

It appears that OpenClaw is only aware of the MessageId and not the parentMessageId. When asked, in a Teams channel, to reply with the runtime context JSON for a specific message, it responded with:

{
  "chat_id": "conversation:19:[email protected]",
  "message_id": "1780422288076",
  "sender_id": "6c76d122-e248-4709-9785-7c1a19c56cd9",
  "conversation_label": "channel",
  "sender": "Chris McFarling",
  "timestamp": "Tue 2026-06-02 13:44 EDT",
  "group_subject": "channel",
  "group_space": "19:[email protected]",
  "inbound_event_kind": "user_request",
  "is_group_chat": true,
  "was_mentioned": true
}

But even if asking OpenClaw to access an attachment in a top-level message, where the parentMessageId is not required for the MS Graph query, OpenClaw fails to query MS Graph.