Summary

• Problem: MSTeams application/vnd.microsoft.teams.file.download.info attachments can expose SharePoint/OneDrive downloadUrl values that require Graph auth, but the download path used those URLs directly.
• Solution: Route eligible downloadUrl values through the existing Graph shares URL helper before downloading.
• What changed: resolveDownloadCandidate() now applies tryBuildGraphSharesUrlForSharedLink() to file.download.info downloadUrl values, and a regression test locks the Graph-only allowlist/auth path.
• What did NOT change (scope boundary): This does not change non-SharePoint download URLs, inline image handling, logging behavior, or the broader MSTeams media-drop issue tracked separately.

Motivation

• Closes a P1 MSTeams message-loss workflow where DM file attachments can resolve only to a placeholder because the raw SharePoint/OneDrive URL is skipped or cannot authenticate through the existing media downloader.
• This is a narrow follow-up to the existing Graph shares behavior that already existed for the contentUrl path.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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

• Closes [msteams] Inbound file attachments silently fail in DMs — file.download.info downloadUrl not rewritten to Graph shares endpoint #67177
• Related fix(msteams): fetch OneDrive/SharePoint shared media via Graph shares endpoint (#55383) #63942
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: MSTeams file.download.info SharePoint/OneDrive downloadUrl attachments now resolve through https://graph.microsoft.com/v1.0/shares/.../driveItem/content instead of trying to fetch the raw SharePoint URL directly.

• Real environment tested: Disposable OpenClaw checkout on a Linux testserver under /root/openclaw-pr-tests/runs/2026-05-23-msteams-download-info-67177/repo, base f6204d081fc35574c86c0df36fed0cced43db8ef, Node v22.22.2, pnpm 11.2.2.

• Exact steps or command run after this patch:

  • node scripts/run-vitest.mjs extensions/msteams/src/attachments.test.ts -t 'routes file.download.info SharePoint downloadUrl through Graph shares endpoint'
  • node scripts/run-vitest.mjs extensions/msteams/src/attachments.test.ts extensions/msteams/src/attachments/shared.test.ts
  • corepack pnpm exec oxfmt --check --threads=1 extensions/msteams/src/attachments/download.ts extensions/msteams/src/attachments.test.ts
  • pnpm check:changed --base origin/main
  • git diff --check

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Copied terminal output from the disposable OpenClaw checkout after applying this patch:

  $ node scripts/run-vitest.mjs extensions/msteams/src/attachments.test.ts -t 'routes file.download.info SharePoint downloadUrl through Graph shares endpoint'
  1 passed, 20 skipped
  
  $ node scripts/run-vitest.mjs extensions/msteams/src/attachments.test.ts extensions/msteams/src/attachments/shared.test.ts
  2 files passed, 72 tests passed
  
  $ corepack pnpm exec oxfmt --check --threads=1 extensions/msteams/src/attachments/download.ts extensions/msteams/src/attachments.test.ts
  all matched files correctly formatted
  
  $ pnpm check:changed --base origin/main
  passed: extensions typecheck, extensions lint, media download helper guard, runtime sidecar loader guard, runtime import-cycle guard
  
  $ git diff --check
  passed
  

• Observed result after fix: The regression run saved a PDF media item from the MSTeams attachment path. Every fetched URL started with https://graph.microsoft.com/v1.0/shares/, and the Graph token provider was called. The raw SharePoint host was not fetched in the Graph-only allowlist/auth setup.

• What was not tested: A live Teams tenant and real SharePoint file download were not replayed. This PR does not claim to fix unrelated inline image or broader DM media-drop paths.

• Before evidence (optional but encouraged): Copied terminal output from the same disposable checkout with only the new regression test applied to the old production code:

  $ node scripts/run-vitest.mjs extensions/msteams/src/attachments.test.ts -t 'routes file.download.info SharePoint downloadUrl through Graph shares endpoint'
  AssertionError: expected [] to have a length of 1 but got +0
  

Root Cause (if applicable)

• Root cause: resolveDownloadCandidate() had already learned to normalize SharePoint/OneDrive shared contentUrl values through Graph shares, but the application/vnd.microsoft.teams.file.download.info branch returned content.downloadUrl directly.
• Missing detection / guardrail: No regression test covered a file.download.info attachment where only graph.microsoft.com was allowed/authenticated and the source downloadUrl was a SharePoint shared link.
• Contributing context (if known): PR fix(msteams): fetch OneDrive/SharePoint shared media via Graph shares endpoint (#55383) #63942 fixed the related contentUrl path, but the Teams-specific downloadUrl branch remained outside that guardrail.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/msteams/src/attachments.test.ts
• Scenario the test should lock in: A Teams file.download.info attachment with a SharePoint downloadUrl should be rewritten to the Graph shares endpoint, use Graph auth, and save the downloaded document media.
• Why this is the smallest reliable guardrail: It exercises the MSTeams attachment resolver and downloader behavior around host allowlists, auth allowlists, token selection, and persistence without needing live tenant credentials.
• Existing test that already covers this (if any): Existing shared-link tests covered contentUrl, not the file.download.info downloadUrl branch.
• If no new test is added, why not: N/A. A new regression test is added.

User-visible / Behavior Changes

MSTeams DM file attachments that arrive as file.download.info with SharePoint/OneDrive download URLs can now download through the existing Graph shares flow when Graph auth is configured, producing actual inbound media instead of only a placeholder.

Diagram (if applicable)

Before:
Teams file.download.info -> raw SharePoint downloadUrl -> media fetch/auth fallback -> empty media result

After:
Teams file.download.info -> Graph shares URL -> Graph auth fetch -> stored inbound document media

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) Yes
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: Eligible Teams file download links are normalized to the existing Graph shares content endpoint instead of the raw SharePoint/OneDrive URL. This reuses the existing Graph auth fallback and existing media host allowlist/auth-allowlist checks; it does not introduce a new token source or broaden file access beyond the configured Graph permissions.

Repro + Verification

Environment

• OS: Linux disposable testserver checkout
• Runtime/container: Node v22.22.2, pnpm 11.2.2
• Model/provider: N/A
• Integration/channel (if any): MSTeams attachment download path
• Relevant config (redacted): Regression test configured media allow/auth hosts to permit graph.microsoft.com for the download path.

Steps

1. Add the regression test for a file.download.info attachment carrying a SharePoint downloadUrl.
2. Run the focused test before the production change to confirm the old path returns no media.
3. Apply the production change to rewrite eligible downloadUrl values through Graph shares.
4. Run focused, adjacent, formatting, and changed-workspace checks.

Expected

• The Teams file.download.info SharePoint/OneDrive downloadUrl is fetched through the Graph shares endpoint with Graph auth and produces a stored document media item.

Actual

• Before the fix, the focused regression test returned an empty media list.
• After the fix, the focused regression test produced the expected PDF media item and all validation commands passed.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

The required copied terminal output is included directly in the Real behavior proof section above so the PR-body gate can evaluate it.

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: I verified the exact old failure and new success in a disposable checkout by running the focused regression test red against the old production code and green after this patch. I also verified adjacent MSTeams attachment/shared-link tests, formatting, changed-workspace checks, and whitespace checks.
• Edge cases checked: The new test constrains the media host/auth path to Graph and asserts that fetched URLs use the Graph shares endpoint instead of the raw SharePoint URL.
• What you did not verify: I did not replay a live Teams tenant upload with real SharePoint credentials, and I did not verify unrelated inline image attachment paths.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

No review conversations exist yet for this new draft PR.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: A live tenant could expose a Teams downloadUrl shape not represented by the regression fixture.
  • Mitigation: The production change uses the existing shared-link parser and falls back to the original downloadUrl when the URL cannot be converted.
• Risk: This fix may be mistaken for a complete fix for all MSTeams media drops.
  • Mitigation: The PR scope is explicitly limited to the file.download.info downloadUrl branch and does not claim broader inline image coverage.