OpenClaw Main Repairs Workspace Attachment Delivery Across Seven Channel Paths

OpenClaw has merged a cross-channel repair for agent-created files that were approved inside a workspace but then failed—or crossed the wrong file-reading boundary—when delivery moved into a plugin. Matrix, Telegram, Slack, iMessage, Discord, Feishu and Microsoft Teams paths are affected by the landed set.

A separate Teams fix prevents a later generated file from replacing an earlier same-named SharePoint item and leaving users with stale or wrong content.

These changes are on main. Operators should stage only the adapters they use and test both allowed and forbidden files; proving successful upload alone does not prove the security boundary survived.

One capability must survive the plugin boundary

The repeated defect was not simply “relative paths are hard.” OpenClaw’s host had already approved a specific workspace and owned the safe media reader, but some plugin send, reply, card, voice-note or upload paths lost that capability and resolved the file elsewhere.

The result depended on the adapter:

• Matrix and Telegram direct Gateway or message-tool sends could report a missing file or drop the attachment;
• Slack sends and upload actions could resolve against the wrong directory;
• Discord voice and thread attachments could fail despite workspace approval;
• Feishu direct, threaded, card, fallback and sequence paths could lose upload access;
• Teams action, message, outbound and upload paths could reject approved files; and
• iMessage could both reject legitimate workspace attachments and bypass host-owned safeguards for unsafe local content.

That final case shows why replacing the reader with a broad filesystem fallback would be the wrong fix. Availability and confinement must move together.

Teams had a second, independent identity problem

PR #113560 reports that generated files commonly reuse names such as image-1.jpg. SharePoint’s replacement behavior could overwrite the previous drive item in place. Teams caches file cards by the item URL, so users could keep seeing stale content while earlier content was lost.

The merged correction requests rename-on-conflict so each accepted upload receives a distinct item instead of silently replacing the prior object.

Filename equality is not content identity. Workflows that reconcile only by name should be changed to retain provider item IDs and URLs.

Safe acceptance matrix

For every enabled channel in a containing build, test:

Use synthetic files with embedded unique markers and no sensitive data. Compare hashes before and after delivery where the provider allows safe download, but never weaken production file policy merely to make the test pass.

Rollout and reconciliation

1. identify the exact release or revision containing the relevant channel PR;
2. preserve existing workspace and media policy;
3. stage one adapter at a time;
4. test every send surface you expose, not only basic messages;
5. record provider file identity, thread identity and OpenClaw’s delivery result; and
6. inspect prior Teams threads for repeated filenames before assuming an old card references the intended bytes.

If a user previously saw “missing file,” do not automatically replay it. Confirm that no fallback path delivered the attachment elsewhere and that the intended conversation is still appropriate.

Interpretation: host-approved media access is a capability, not a pathname string. Plugins should receive that narrow capability intact; they should not reconstruct authority from a relative path.

Evidence and limits

The official merged-PR and commit records in the repository packet establish the affected adapters, the host-owned media boundary and the SharePoint conflict behavior. Direct GitHub extraction returned HTTP 403, and several upstream PR records were labelled as needing additional proof despite being merged. OpenClaw Academy did not send files through live provider accounts. Stage the containing build rather than treating upstream test labels as production evidence.

Bottom line

This is both a delivery and a security-boundary upgrade. Adopt it by proving two things together: an approved workspace file reaches the exact intended destination, and an unapproved or unsafe file still cannot cross the host boundary.