Summary

On Hermes 563ed0e6, QQ C2C attachments whose payload comes through as content_type=file are never treated as images, even when the filename is clearly an image (for example .png).

As a result, image-bearing QQ messages can enter the agent as plain text plus [Attachment: ...] notes instead of media_urls/media_types, so the normal vision enrichment path never runs.

Environment

• Hermes commit: 563ed0e6
• Platform: qqbot
• Observed on macOS

Expected behavior

If a QQ attachment has a filename like *.png, *.jpg, *.jpeg, *.webp, or *.gif, Hermes should treat it as an image even when QQ reports content_type=file, so the attachment is cached as an image and passed into the normal vision pipeline.

Actual behavior

The attachment is handled as a generic document/file instead of an image:

• images=0, voice=0 after processing
• the session gets [Attachment: ...png] style text instead of an image path in media_urls
• downstream agent behavior can go badly off course because the design image never enters _prepare_inbound_message_text() as an image for vision analysis

Reproduction

1. Start Hermes gateway with qqbot enabled.
2. In a QQ C2C chat, send:
   • a text instruction that refers to a design image
   • a zip attachment
   • a PNG attachment
3. Observe the QQ payload/logs for the PNG attachment:
   • content_type=file
   • filename=...png
4. Hermes logs show After processing: images=0, voice=0 for that PNG message.

Evidence

Observed failing case:

2026-04-23 11:22:21,783 attachment[0]: content_type=file ... filename=icons_512_whitefeather.zip
2026-04-23 11:22:22,186 After processing: images=0, voice=0
2026-04-23 11:22:22,306 attachment[0]: content_type=file ... filename=ChatGPT Image 2026年4月22日 16_20_44.png
2026-04-23 11:22:22,760 After processing: images=0, voice=0

Code path only treats content_type.startswith("image/") as image input:

• gateway/platforms/qqbot/adapter.py:1146-1194
• gateway/platforms/qqbot/adapter.py:1228-1237

Relevant code excerpt:

elif ct.startswith("image/"):
    cached_path = await self._download_and_cache(url, ct)
    ...
else:
    cached_path = await self._download_and_cache(url, ct)
    other_attachments.append(f"[Attachment: {filename or ct}]")

And _download_and_cache() also relies on content_type.startswith("image/"):

if content_type.startswith("image/"):
    return cache_image_from_bytes(data, ext)
...
else:
    return cache_document_from_bytes(data, filename)

Useful contrast

The same adapter works correctly when QQ sends a real image MIME type:

2026-04-22 11:26:07,916 attachment[0]: content_type=image/png ... filename=F8CE9C97E15824BE3AC4D4933857C7C3.png
2026-04-22 11:26:08,172 After processing: images=1, voice=0

So this looks specifically like a QQ payload-shape gap for attachments that are actually images but arrive as content_type=file.

Suspected fix

In the QQ adapter, add filename/extension-based fallback classification for attachments whose content_type is generic (file, application/octet-stream, empty, etc.).

Likely places:

• gateway/platforms/qqbot/adapter.py::_process_attachments()
• gateway/platforms/qqbot/adapter.py::_download_and_cache()

Something along the lines of:

• if content_type is not image/audio/voice but filename ends with an image extension, treat it as image
• optionally sniff the downloaded bytes as a secondary fallback

Impact

This breaks a common real workflow for QQ-based Hermes usage: sending a design screenshot / mockup / reference image to drive frontend work. The agent receives the task text, but not the actual image input, so it can analyze the wrong local files or proceed without the intended visual context.