openclaw - 💡(How to fix) Fix Prompt Request: Signal inbound media surfaces as media:// URIs not resolvable by any built-in tool

Prompt Request: Signal inbound media surfaces as media://inbound/<file> URIs that no built-in tool can resolve

Environment

• OC: 2026.5.16-beta.4 (commit 38c3a8d)
• Channel: Signal (extensions/signal), single-account daemon mode

Reproduction

1. Bind an agent to the Signal channel (bindings[].match.channel = "signal").
2. Send the bot a file attachment via Signal.
3. Watch the agent trajectory.

Observed The user message reaches the agent with the attachment expressed as a URI:

[media attached: media://inbound/2025122200_Warning---abc.geojson]

The agent (gpt-4o-mini in our case) reasonably calls read on it. read treats media:// as a relative path and concatenates it under the workspace dir, producing a corrupted path:

ENOENT: no such file or directory, access '/home/clawbot/.openclaw/workspace-flood-claw/media:/inbound/2025122200_Warning---abc.geojson'

Note the media:/ segment with the stray colon — the URI scheme is being injected verbatim into the filesystem path. exec ls media://inbound/ fails for the same reason. The agent has no built-in way to discover or open the file.

The file is on disk at /home/clawbot/.openclaw/media/inbound/<filename> — but the agent only knows this if its skill prompt happens to teach the convention. Every skill author has to discover this independently after watching their agent fail in production.

For comparison, the WhatsApp channel exposes $MEDIA_PATH as an env var that resolves to the same on-disk path, so skill authors can just write curl --data-binary @"$MEDIA_PATH". Signal has no such handle.

Expected (any one of these would close the gap)

1. Built-in: the read and exec tools resolve media://inbound/<file> to <OPENCLAW_HOME>/media/inbound/<file>.
2. Or: a built-in media_resolve tool that takes a media:// URI and returns the absolute on-disk path.
3. Or: parity with WhatsApp — set $MEDIA_PATH (and $MEDIA_URI if useful) in the agent's runtime context for Signal inbound too.

Files of interest

• dist/extensions/signal/* — where inbound media gets attached to the user message
• The read tool implementation (whichever module owns it) — currently scheme-blind

Acceptance criteria

• An agent receiving a Signal-attached file can access it via at least one documented mechanism without skill-author intervention
• The mechanism is symmetrical to WhatsApp (or both channels use the same one)
• Behavior is documented under docs/channels/signal/ (or wherever the media flow lives)

Workaround Each skill's AGENTS.md / SKILL.md must teach the agent to strip media:// and prepend <OPENCLAW_HOME>/. We've added this to our Flood-Claw skill; it works but is brittle.