hermes - 💡(How to fix) Fix Windows: MEDIA: file delivery silently fails for unquoted drive-letter paths (extract_media)

Summary

On Windows, delivering a file from the agent via the MEDIA:<path> convention (used by the send_message tool and by gateway response delivery) silently fails for unquoted Windows drive-letter paths — the MEDIA: tag is neither extracted nor stripped, so it leaks into the chat as literal text and the file is never sent. Quoting the path works.

Observed on v0.15.1 (2026.5.29), Windows 11, Telegram gateway. Affects all file types (images, charts, PDFs, …). It appears to be a regression — file delivery worked on the prior release.

Repro

from gateway.platforms.base import BasePlatformAdapter

# Unquoted Windows drive-letter path — FAILS (no match; leaks as text, no file sent)
BasePlatformAdapter.extract_media("MEDIA:C:/Users/me/pic.png")
# -> ([], 'MEDIA:C:/Users/me/pic.png')

# Quoted — WORKS (file extracted, tag stripped)
BasePlatformAdapter.extract_media('MEDIA:"C:/Users/me/pic.png"')
# -> ([('C:/Users/me/pic.png', False)], '')

# A '/'-rooted path also works
BasePlatformAdapter.extract_media("MEDIA:/c/Users/me/pic.png")
# -> ([('/c/Users/me/pic.png', False)], '')

Root cause

extract_media's MEDIA:<path> regex (gateway/platforms/base.py) accepts a quoted path of any form, but the only unquoted branch is (?:~/|/)\S+…, which requires the path to start with / or ~/. A Windows drive-letter path (C:/… or C:\…) matches neither, so unquoted Windows paths are dropped.

Notably, the send_message tool's own parameter description shows an unquoted Unix example (MEDIA:/tmp/report.pdf), so models on Windows naturally emit unquoted drive-letter paths — and the send silently fails.

Suggested fix

Add a Windows drive-letter alternative to the unquoted-path branch of the regex, e.g. accept [A-Za-z]:[\\/]\S+… alongside the existing (?:~/|/)\S+….

(Worked around locally by normalizing/quoting the path before extract_media runs.)