#2850: Agent receives virtual MEDIA: path instead of real attachment path — cannot operate on uploaded files

Bug Description

When a user uploads a file (image, PDF, etc.) via the WebUI attachment button, the message shown to the user includes a virtual MEDIA:/root/workspace/<filename> path. However, this path does not exist on disk — it is a display-only virtual path.

The actual file is stored at:

~/.hermes/webui/attachments/<uuid>/<original_filename>

The Agent (receiving this message) cannot use this virtual path to read, copy, parse, or analyze the file. Tools like read_file, terminal cp, vision_analyze, and PDF parsers all fail with ENOENT.

Current Workaround

The downstream consumer has to work around this by:

1. Extracting the filename from the MEDIA: message
2. Running find ~/.hermes/webui/attachments/ -name "*<filename>*" to locate the real path
3. Using the resolved real path for all file operations

This is fragile and error-prone. Different upload sessions produce different UUIDs, and multiple files with the same original name can coexist under different UUIDs.

Expected Behavior

The Agent should receive the real absolute path of the uploaded attachment instead of the virtual MEDIA:/root/workspace/... display path.

Alternative: provide a dedicated API endpoint (e.g. /api/file/resolve?filename=...&uuid=...) that returns the real path, so the Agent can query it programmatically.

Related

• #2631: Bug: Attachment uploads use blob: URLs causing native image mode to fail
• #2780: Bug: Pasted images can not be seen by agent in a chat

Distinct from #2631/#2780: those are about inline pasted images / blob URLs. This issue is about the Agent-side message content providing a non-existent virtual path for properly uploaded file attachments.