Fix chat upload image attachment paths

[george-andraws]

Thinking Path

• Hermes WebUI should give the agent immediate access to files uploaded in a chat turn.
• /api/upload already returns the absolute server-side attachment path.
• The frontend preserved that path in structured attachment metadata, but the text context sent to the agent downgraded image uploads to bare filenames.
• In text/tool-mode image handling, the agent then saw [Attached files: Screenshot.jpg] instead of a readable path, so tools such as vision_analyze could not open the upload immediately.
• Display rendering should remain friendly-name based, while agent-facing context should prefer the real server path.
• A follow-up duplicate-upload audit found that same-filename uploads in the same session could overwrite the previous attachment, which could make image behavior appear intermittent.

What Changed

• Updated static/messages.js so uploadedPaths uses this fallback order for every uploaded item:
  • u.path
  • u.name
  • u.filename
  • u
• Left uploadedNames unchanged so optimistic UI, inflight state, and attachment chips still display friendly names.
• Updated _upload_destination() in api/upload.py so repeated uploads with the same sanitized filename in one session get unique paths such as photo.png, photo-1.png, instead of overwriting earlier files.
• Added regression coverage for both behaviors:
  • image upload agent context uses the server path
  • duplicate same-filename uploads preserve both files
• Added an Unreleased changelog note for duplicate upload filename handling.

Why It Matters

When a user uploads an image and asks the agent to inspect it, the agent must be able to find the file immediately. Sending only the filename breaks that handoff because uploads live under the WebUI attachment inbox, not necessarily in the selected workspace or current working directory.

The duplicate-filename fix removes a plausible intermittent case: uploading the same image, or two files with the same name, no longer mutates the previous attachment path's contents.

Verification

• gh pr checks 2940 --repo nesquena/hermes-webui --watch
  • test (3.11) passed in 2m03s
  • test (3.12) passed in 2m21s
  • test (3.13) passed in 2m14s
• /Users/georgeandraws/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_sprint1.py::test_upload_destination_does_not_overwrite_same_filename tests/test_chat_upload_attachment_paths.py tests/test_native_image_attachments.py tests/test_issue1867_upload_size_preflight.py -q
  • 46 passed
• /Users/georgeandraws/.hermes/hermes-agent/venv/bin/python -m pytest -q
  • Broad local suite exposed unrelated environment-sensitive failures in this machine's test setup:
    • real local skills include Systematic Debugging, and older tests interpolate the name without URL encoding
    • local git init defaults to main while two tests assume master
    • isolated temp paths can appear as /private/var vs /var on macOS
  • Failing slices pass when rerun with isolated Hermes state and matching Git defaults where applicable.

Risks / Follow-ups

Low risk. The path-context change only affects the agent-facing text sent to /api/chat/start; structured attachment metadata and UI display names remain friendly-name based.

Duplicate upload filename handling is a small behavior change: the second same-name upload now returns a suffixed filename/path instead of overwriting the first file. This should be safer for chat attachment history.

Model Used

AI-assisted.

• Primary assistant: OpenAI GPT-5.5 via Hermes WebUI
• Coding delegate: OpenAI Codex CLI codex-cli 0.133.0, model gpt-5.5

[nesquena-hermes]

Merged in Release DG / v0.51.135 (stage-batch17, batch with PRs #2906 #2912 #2917 #2919 #2921 #2922 #2927 #2936 #2940).

Thanks @george-andraws! 🚢

[nesquena-hermes]

The second commit a7e19b78 ("fix duplicate chat upload filenames") was cherry-picked into Release DI / v0.51.137 (stage-batch19) as commit 0f388de0 on master.

The first commit fe597c1c ("fix chat upload attachment paths") was already shipped via stage-batch17 / v0.51.135 earlier today, so this PR can be closed once GitHub reconciles. Both upload-related fixes are now live on master.

Thanks @george-andraws! 🚢

[nesquena-hermes]

Both commits from this PR are now on master (fe597c1 via stage-batch17, a7e19b7 cherry-picked into stage-batch19 as 0f388de). Closing.

Thanks @george-andraws!