Summary

The gateway media auto-append logic can treat literal MEDIA: examples from ordinary tool output as real attachments.

This is platform-neutral and not specific to any one gateway adapter. Any messaging gateway can hit it if a normal tool result contains documentation, logs, search output, or skill text with a literal media-tag example.

Problem

When the final response does not contain a media tag, the gateway currently has logic that scans tool/function output for MEDIA: strings and appends matching paths to the final gateway reply.

That is too broad. A documentation or skill tool may legitimately return an example like:

MEDIA:/absolute/path/to/file.png

That string is documentation, not a real artifact. But the broad scanner can treat it as an attachment and try to send a nonexistent file.

Minimal reproduction

Construct a conversation where the assistant calls a documentation-like tool such as skill_view, and the tool result contains a media example:

messages = [
    {
        "role": "assistant",
        "tool_calls": [
            {"id": "call_skill", "function": {"name": "skill_view"}}
        ],
    },
    {
        "role": "tool",
        "tool_call_id": "call_skill",
        "content": "Example usage: MEDIA:/absolute/path/to/file.png",
    },
]

Old broad behavior:

['MEDIA:/absolute/path/to/file.png']

Expected behavior:

[]

A positive case should still work for real media-producing tools:

messages = [
    {
        "role": "assistant",
        "tool_calls": [
            {"id": "call_tts", "function": {"name": "text_to_speech"}}
        ],
    },
    {
        "role": "tool",
        "tool_call_id": "call_tts",
        "content": "MEDIA:/tmp/voice.mp3 [[audio_as_voice]]",
    },
]

Expected behavior:

['MEDIA:/tmp/voice.mp3']

Expected behavior

Auto-append should only consider outputs from tools that intentionally produce media artifacts, such as text_to_speech.

Documentation tools, skill tools, search tools, logs, and arbitrary tool outputs should not trigger attachment sending just because they contain a literal MEDIA: example.

Suggested fix

Use an allowlist of media-producing tool names for auto-append extraction instead of regex-scanning all tool/function output.

For example:

_AUTO_APPEND_MEDIA_TOOL_NAMES = {"text_to_speech", "text_to_speech_tool"}

Then only scan tool results whose tool_call_id maps back to an assistant tool call with an allowlisted tool name.

Why this matters

Without this boundary, ordinary documentation or tool output can cause the gateway to attempt sending nonexistent or unintended files. The producing tool should be the trust boundary for automatic media delivery.

Environment

• OS: macOS Darwin 25.3.0 arm64
• Hermes: v0.11.0 (2026.4.23), local checkout at commit 95c33147
• Runtime shown by hermes --version: Python 3.11.15
• System python3 --version: Python 3.9.6
• Repository remote: https://github.com/NousResearch/hermes-agent.git

No full traceback is produced in the minimal reproduction; the observed failure mode is incorrect media extraction / attempted delivery of a documentation example as an attachment.

Notes

I have a local fix prepared that:

• adds an allowlisted collector for auto-appended media tags;
• ignores MEDIA: examples returned by skill_view and other non-media tools;
• preserves auto-append behavior for text_to_speech outputs;
• adds regression tests for both the negative docs/skill case and the positive TTS case.