fix(desktop): attach non-image web uploads by path instead of failing the read - #60
Merged
Merged
Conversation
… the read (#103) The hosted web SPA (vweb) has no local filesystem. When a .md/text/pdf is dropped it is uploaded to ~/.hermes/uploads via the web shim and attached as a kind:'file' ref pointing at that server path. At submit/eager-upload time uploadComposerAttachment then re-read the file's bytes client-side via window.hermesDesktop.readFileDataUrl(serverPath). The web shim only caches data URLs for IMAGES (uploadBrowserFile gates the cache write on image/* mime), so for any non-image file the read returned '' and the code threw `Could not read <server-name>`, surfaced as the "Drop files / Could not read …md" toast — even though the upload itself had already succeeded. Images worked only because their bytes are cached. Fix: in the hosted web client, skip the client-side byte read for non-image files and attach by path only. The file already lives on the gateway (~/.hermes/uploads, made agent-readable by the upload endpoint's chown), so file.attach resolves the path directly (server.py _stage_session_file_attachment Case 2 reads the bytes and returns an @file: ref). Native Electron remote mode is unchanged — its paths live on the client disk and still upload bytes. Adds a regression test asserting the web client attaches by path with no read and no data_url. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🔎 Lint report:
|
ashneil12
added a commit
that referenced
this pull request
Jul 15, 2026
… dropped __HERMES_WEB_CLIENT__ guard) (#91) The hosted web SPA has no local filesystem — its picked files already live on the gateway box (~/.hermes/uploads/...). When window.__HERMES_WEB_CLIENT__ is set we must attach by PATH and let gateway file.attach read the bytes, never client-read them. The web-shim's readFileDataUrl only caches image previews, so for a .md/.txt it returns '' and the remote branch then threw "Could not read <name>" even though the upload had already succeeded — breaking every non-image attachment from the hosted web chat on webfree boxes. This guard shipped as prod #60 (June 2026) but was dropped from uploadComposerAttachment during a fork reconcile. Canary re-applied it in the 2026-07-15 upstream sync (PR NousResearch#166, commit 61addda147); this ports that exact fix to the prod fork. Guarded by use-prompt-actions/index.test.tsx "hosted web client attaches a non-image file by path only" — verified red→green (21→20 pre-existing failures, zero regressions). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Port of canary fix ashneil12/vanilla-hermes-agent-canary#103 (commit verified live on canary, confirmed by the reporter).
Problem
In the hosted web rich-chat (vweb client), dropping a non-image file (
.md,.txt,.pdf, …) fails with a "Drop files / Could not read<name>" toast. Images work; other files don't. The upload itself succeeds — the file lands at~/.hermes/uploads/<date>/<name>and the chip shows that server path — but the attach then errors.Root cause
The hosted web SPA has no local filesystem. A dropped non-image file is uploaded to
~/.hermes/uploadsvia the web shim and attached as akind:'file'ref pointing at that server path. At submit/eager-upload time,uploadComposerAttachmentre-read the bytes client-side viawindow.hermesDesktop.readFileDataUrl(serverPath)— but the web shim'sreadFileDataUrlonly serves an in-memory cache that's populated for images only. So non-image files return''→null→throw new Error('Could not read ' + label), surfaced as the toast. Images escape only because their bytes are cached at drop time.Fix
In the hosted web client, skip the client-side byte read for non-image files and attach by path only. The file already lives on the gateway, so
file.attachresolves the path directly (_stage_session_file_attachmentCase 2). Nodata_urlround-trip, no 16 MB cap.window.__HERMES_WEB_CLIENT__.Verification
Built into
vanilla-hermes-agent-canary:stableand rolled to a live canary instance; reporter confirmed.md(and other non-image) uploads now attach and are readable by the agent. This PR ships the identical one-commit fix to prod for the fleet rollout.