Repository navigation
app: the attachment card in a sent message is display-only — the uploaded file cannot be opened or downloaded #59896
Description
Description
A file attached to a prompt cannot be opened or downloaded from the sent message. Clicking the attachment card in the transcript does nothing: no new tab, no save dialog, no context menu.
Cause, read from the served 2.1.2 bundle:
- Path-delivered attachments (feat(app): attach any file and deliver unsupported ones by path #49467) are stored only on the server —
<tmp>/uploads/<uuid>/<name>— and the message carriesmetadata.attachments: [{name, mime, path}]. - The message view maps those to
referencesand renders each as a card with noonClickand noclickableflag. The download handler (openAttachment→<a download>over adata:/urisource) is wired only for parts that still carry asource, i.e. the pre-feat(app): attach any file and deliver unsupported ones by path #49467 inline shape. - There is no route that streams a server file:
/api/fs/readanswers JSON{type:"binary", content:"<base64>", mimeType}.
Effect: the bytes stay on the server and the client offers no way to get them back. When the file came from a remote client it also lives in the server's temp directory, so a reboot loses it silently.
Expected: clicking the card opens (or downloads) exactly the file that was attached — the same action the composer card offers before sending.
Plugins
None.
OpenCode version
2.1.2 (server opencode serve 2.1.2, web UI in Firefox)
Steps to reproduce
- Connect a client to a remote server, so the attachment is written to
<tmp>/uploads/<uuid>/<name>. - Pick a model that does not read PDFs natively, attach a PDF and send it — the attachment is then delivered by path.
- Click the attachment card in the sent message: left click, then right click. Nothing happens.
- Compare with an image attachment sent to a model that reads images: that card is clickable and opens a preview.
Screenshot
Not attached — the click produces no dialog, so the screenshot is just the transcript card.
Operating System
Client: Windows 11 (Firefox). Server: Ubuntu 24.04, Linux 6.8, x86_64.
Terminal
Browser; server shell /bin/bash.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up and for tracing it through the bundle!
You're asking for the attachment card on a sent message to open or download the file that was attached, including files delivered by path and uploaded to a remote server's
<tmp>/uploads/….Your reading matches the code. Since #49467, attachments delivered by path appear in the transcript as cards drawn from
metadata.attachments, and those cards are display-only. Only inline attachments that still carry their data are wired to the open/download action. Files on a remote server would also need a way to read them back to the client. That makes this new functionality rather than a regression, so I've filed it as a feature request. Maintainers will consider it.Related issues and PRs:
OvchinnikovKirill commentedon Oct 28, 2026
Two facts that put this above a plain nice-to-have:
The card points at a path that can disappear. On a remote server the upload exists only in the temp upload directory, so after a reboot the transcript still renders the attachment card while the file is gone — silently, with no error state. That is the same gap [FEATURE]: upload attachments to the server so agent tools can read them (managed per-session store) #46173 describes for the store; here it is visible as a dead card in history.
The click target already exists for one MIME class. fix(app): preview image attachments delivered by path #57249 made path-delivered
image/*cards previewable, reading the bytes throughfs/read; the card for any other MIME type is the same hop, just without a renderer. And feat(server): add experimental GET /api/experimental/media/:hash and opt-in experimental-media-uri capability #59103's opt-inGET /api/experimental/media/:hashis a second way to the bytes onceexperimental.media_blobbecomes default.So the ask stays narrow: not a file manager (#39878 was declined, and rightly so) — just that the card for a file the user himself sent resolves to that file, the way the composer card does before sending.