Skip to content

msteams: fix image download auth, double-counting, and typing indicator#26274

Closed
nicksav wants to merge 8 commits intoopenclaw:mainfrom
nicksav:msteams/fix-image-download-and-typing
Closed

msteams: fix image download auth, double-counting, and typing indicator#26274
nicksav wants to merge 8 commits intoopenclaw:mainfrom
nicksav:msteams/fix-image-download-and-typing

Conversation

@nicksav
Copy link
Copy Markdown

@nicksav nicksav commented Feb 25, 2026

Summary

  • Problem: When users paste/attach images in Teams DMs, the bot cannot download them because the Bot Framework attachment service URL at smba.trafficmanager.net requires a Bearer token, but the msteams extension never attempts auth for that host. Additionally, image count is incorrectly reported as "2 images" for a single image, and there is no typing indicator while images are being downloaded.
  • Why it matters: Images sent in Teams DMs are completely invisible to the bot, making the extension unusable for image-based workflows.
  • What changed:
    1. Added trafficmanager.net (Bot Framework attachment service) and Skype CDN hosts (asm.skype.com, ams.skype.com, media.ams.skype.com) to DEFAULT_MEDIA_AUTH_HOST_ALLOWLIST
    2. Refactored fetchWithAuthFallback to send auth token upfront for known-protected hosts instead of making a wasted unauthenticated request that always returns 401/403
    3. Relaxed the Graph API fallback condition to trigger when there are mixed attachment types (not just HTML-only), and when inline <img> tags are detected
    4. Fixed buildMSTeamsAttachmentPlaceholder to avoid double-counting when both an image/* attachment and an HTML <img> tag reference the same image
    5. Added typing indicator immediately when attachments are detected, using adapter.continueConversation for proactive messaging to avoid revoked TurnContext proxy errors
    6. Improved "graph media fetch empty" log message to include attempt details for easier debugging
  • What did NOT change: No changes to outbound messaging, reply formatting, or channel configuration schema.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Related: Teams image download failures in 1:1 DM conversations

User-visible / Behavior Changes

  • Images pasted in Teams DMs are now downloaded and visible to the agent (previously showed <media:image> placeholder only and agent could not see image content)
  • Single image sends now correctly report "1 image" instead of "2 images"
  • Users see a typing indicator while the bot downloads image attachments

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No — uses the existing Bot Framework token provider, just for additional known-Microsoft hosts
  • New/changed network calls? Yes — authenticated requests are now sent to smba.trafficmanager.net and Skype CDN hosts using the existing BF token. Previously these requests were unauthenticated and failed with 401/403.
  • Command/tool execution surface changed? No
  • Data access scope changed? No
  • Risk + mitigation: The auth token is only sent to hosts explicitly listed in DEFAULT_MEDIA_AUTH_HOST_ALLOWLIST. All added hosts are official Microsoft/Bot Framework domains. The Bot Framework token was already available and used for messaging.

Repro + Verification

Environment

  • OS: Linux (Azure VM, Ubuntu)
  • Runtime: Node 22, pnpm
  • Model/provider: Anthropic Claude Sonnet 4.6
  • Integration/channel: Microsoft Teams via Bot Framework (Azure Bot Service)
  • Config: msteams channel with appId, webhook on port 3978, dmPolicy: open, Azure AD app with Chat.Read.All application permission

Steps

  1. Send a DM to the bot in Microsoft Teams
  2. Paste or attach an image in the message
  3. Observe the bot's response

Expected

  • Bot downloads and processes the image
  • Bot responds with image-aware content
  • Typing indicator shows during image processing

Actual (before fix)

  • Bot responds with <media:image> placeholder text and says it cannot see the image
  • Bot reports "2 images" for a single image
  • No typing indicator during the ~5s image download

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets

Before fix - logs show:

"html attachment summary"
"inline images detected but none downloaded"

After fix - image downloads successfully and bot describes image content.

All 20 msteams attachment tests pass (pnpm vitest run extensions/msteams/src/attachments.test.ts).

New test added for double-counting regression: does not double-count when image attachment and HTML img tag refer to the same image.

Human Verification (required)

  • Verified: End-to-end image download works in Teams DM (bot correctly describes image content)
  • Verified: Single image no longer reports "(2 images)"
  • Verified: Typing indicator appears immediately when image attachments are detected
  • Verified: No Cannot perform 'get' on a proxy that has been revoked errors from typing indicator
  • Edge cases checked: clipboard-pasted images in Teams DMs
  • Not verified: Channel/group chat image downloads, file attachment downloads (non-image)

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Failure Recovery (if this breaks)

  • Revert this PR; image downloads will return to the previous (broken) state for Teams DMs
  • No config changes to restore
  • Known bad symptoms: auth token being sent to unintended hosts (check DEFAULT_MEDIA_AUTH_HOST_ALLOWLIST entries)

Risks and Mitigations

  • Risk: Auth token sent to additional hosts (trafficmanager.net, asm.skype.com, ams.skype.com, media.ams.skype.com)
    • Mitigation: All hosts are official Microsoft/Bot Framework domains already used by Teams infrastructure; token is the existing BF token already used for messaging

Made with Cursor

Greptile Summary

This PR fixes three critical issues in the msteams extension: image downloads from Bot Framework attachment service (smba.trafficmanager.net) that were failing with 401 errors, incorrect "2 images" count for single images, and missing typing indicators during image downloads.

Key changes:

  • Added trafficmanager.net and Skype CDN hosts (asm.skype.com, ams.skype.com, media.ams.skype.com) to the auth allowlist
  • Refactored fetchWithAuthFallback to send auth tokens upfront for known-protected hosts instead of wasting a request that always returns 401
  • Fixed double-counting logic in buildMSTeamsAttachmentPlaceholder to avoid counting the same image twice when both explicit attachment and HTML <img> tag exist
  • Relaxed Graph API fallback condition to trigger when HTML attachments are present (not just HTML-only)
  • Added typing indicator immediately when attachments are detected
  • Moved all messaging to proactive continueConversation pattern to avoid TurnContext proxy revocation errors

All changes are backward compatible. Tests have been updated and a new test case added for the double-counting regression.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The changes are well-tested with comprehensive test coverage including a new test case for the double-counting regression. The auth token is only sent to explicitly allowlisted Microsoft/Bot Framework domains. The refactoring to use proactive messaging is cleaner and avoids TurnContext revocation issues. The changes are backward compatible with no breaking changes to config or external APIs.
  • No files require special attention

Last reviewed commit: 24c3b54

(2/5) Greptile learns from your feedback when you react with thumbs up/down!

@openclaw-barnacle openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: M labels Feb 25, 2026
@openclaw-barnacle
Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Mar 3, 2026
@BradGroux BradGroux self-assigned this Mar 10, 2026
@BradGroux
Copy link
Copy Markdown
Member

Hi @nicksav — thanks for the submission. I’m the new Microsoft Teams maintainer for OpenClaw. Please give me a day or two to work through the open Teams backlog. Also, join the Twitter community for daily MS Teams feedback + updates: https://x.com/i/communities/2031170403607974228

1 similar comment
@BradGroux
Copy link
Copy Markdown
Member

Hi @nicksav — thanks for the submission. I’m the new Microsoft Teams maintainer for OpenClaw. Please give me a day or two to work through the open Teams backlog. Also, join the Twitter community for daily MS Teams feedback + updates: https://x.com/i/communities/2031170403607974228

@BradGroux
Copy link
Copy Markdown
Member

Closing this stale Microsoft-tracker item for cleanup. If this is still an issue or still worth pursuing, please re-open it. We now have dedicated Microsoft maintainers watching this area.

@BradGroux BradGroux closed this Mar 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

channel: msteams Channel integration: msteams size: M stale Marked as stale due to inactivity

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants