[Bug] HTML attachments with a workspace sourcePath skip the download dialog

[Astro-Han]

Affected area

Desktop app

Installation method

Desktop release

Lody version or commit

0.89.4

Operating system

macOS 26.6.2 arm64

Agent or runtime

Grok agent in a local Desktop session (same-machine CLI)

What happened?

Clicking an HTML file uploaded with lody_upload_files never offers a download. The attachment is treated as a live HTML preview of the workspace file.

lody_upload_files documents the opposite: the file is attached as a downloadable artifact, and plain-text files may additionally preview inline. For .html, the download path is skipped entirely when the upload records a workspace-relative sourcePath.

What the client does:

1. SessionFileGroup.handlePreview short-circuits when isHtmlSessionFile(file) && openHtmlFile?.(file) returns true (packages/components/src/components/ai-gui/view.tsx).
2. On a local session, resolveSessionHtmlAttachmentAction returns { kind: 'open-local-file' } whenever sourcePath passes isSessionFileSourcePath (packages/components/src/components/sessions/session-html-attachment-action.ts). Relative paths such as .lody/page.html qualify; only .., absolute, and drive-letter paths are rejected (packages/shared/src/ai.ts).
3. That opens a file-viewer tab with previewHtml: true (session-detail.tsx handleOpenHtmlFile). SessionFilePreviewDialog, which is the surface that has Copy / Download, is never shown.

The MCP tool writes nothing new into the workspace file area, but if the agent uploads a path that is already inside the session workspace, the CLI records sourcePath as provenance. Local HTML clicks then always go to the live file viewer.

On a remote session the same click is worse: an active Browser connection or an available previewCandidate wins, so the HTML attachment can open the agent-reported loopback port instead of the file bytes.

What did you expect?

An HTML attachment uploaded to the conversation should stay downloadable, matching the lody_upload_files contract and the existing preview dialog's Download action.

Live file preview / Browser can remain an extra action. It should not replace download when the user is trying to save the attached bytes.

How can we reproduce it?

1. Open a local Desktop session whose machine is this computer.
2. Have the agent write a self-contained demo.html inside the session workspace (any relative path without ..).
3. Have the agent call lody_upload_files on that path.
4. Click the resulting HTML attachment in the chat.
5. Observe: a file-viewer HTML preview opens. The attachment preview dialog with Download does not appear.
6. There is no other control on the card that downloads the attached bytes.

Control: upload a .txt or .zip the same way. Those cards still preview and/or download.

Remote variant: on a session whose agent has already reported a preview candidate, click an HTML attachment that is unrelated to that port. The UI asks to connect to the reported port instead of showing the file.

How often does it happen?

Every time

Relevant log output

No CLI exception. Client routing is deterministic from the sources above.

Additional context

Searched existing issues for HTML attachment / download / preview. No duplicate. Related changelog entries (0.86.2 self-contained HTML preview, 0.87.0 HTML attachments opening live previews) look like the feature that introduced this routing, not a fix for download.

I am not reporting the separate Browser probe error Local preview server did not respond over HTTP: fetch failed here. In the same session that string appeared after opening Browser against an agent-reported loopback port; TCP connected and the HTTP server then closed with an empty body. That is outside this attachment-routing bug.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.

[hasak21]

I've submitted a PR in #342 to address this — it preserves the preview/download dialog for HTML files while offering a dedicated button to open the live preview when provenance is available.