Summary

In VPN/proxy environments where Discord CDN domains resolve to private/reserved IP ranges (198.18.x.x), the SSRF guard blocks attachment downloads during inbound message processing. Instead of degrading gracefully (passing attachment metadata to the agent), the entire attachment is silently dropped from the agent's inbound context.

Steps to reproduce

Steps to Reproduce

Run OpenClaw behind a TUN-mode VPN where all DNS resolves to private/reserved IP ranges (e.g. 198.18.x.x)
Send a message with a file or image attachment in a Discord DM or guild channel
The agent receives the message text but has no knowledge of the attachment

Expected behavior

Attachment metadata (filename, URL, content_type, size) should always be passed to the agent context, regardless of whether the CDN download succeeds or fails. If the SSRF guard blocks the download, OpenClaw should degrade gracefully — not silently discard the attachment entirely.

Actual behavior

The agent's inbound context contains only the message text. The attachment is completely absent. However, manually fetching channel history via message(action="read") returns the full attachment data:

"attachments": [
{
"filename": "IMG_2447.jpg",
"size": 234951,
"url": "https://cdn.discordapp.com/attachments/...",
"content_type": "image/jpeg"
}
]

This confirms the raw Discord data is intact — the attachment is being dropped during inbound context construction, not at the Discord API level.

Root Cause (suspected)

In VPN/proxy environments, cdn.discordapp.com and media.discordapp.net resolve to 198.18.x.x (private/reserved IP range). The SSRF guard blocks the download at the IP check stage, and the attachment is then silently discarded instead of passing the metadata through.

This is the same class of issue fixed for BlueBubbles in PR #27599, where private-IP attachment fetches were false-blocked by default SSRF checks. A similar fix — auto-allowlisting Discord CDN hostnames (cdn.discordapp.com, media.discordapp.net) for inbound attachment fetches — should resolve this.
Additionally, even if the download fails for any reason, attachment metadata should never be silently dropped. The fix should ensure the agent always receives at minimum the URL, filename, and content_type.

Impact

Affected users: Anyone running OpenClaw behind a VPN or transparent proxy (TUN mode) — common in regions requiring VPN for internet access
Severity: Blocks workflow — all file and image attachments are completely invisible to the agent
Frequency: Always reproducible in affected network environments
Consequence: Agents cannot process any user-sent files or images via normal chat; requires manual workaround (message read + separate fetch)

Workaround

Ask the agent to manually fetch recent messages via message(action="read") to retrieve attachment URLs, then process separately.

Related

PR #27599 — BlueBubbles SSRF fix (same pattern)
Issue #28296 — initial report (attachment missing from inbound context)

OpenClaw version

2026.2.26

Operating system

macOS (Darwin arm64)

Install method

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Network: TUN-mode VPN, all DNS resolves to 198.18.x.x