[feature]: Match Web UI behavior for file attachments (Show "Open" / "Abrir" instead of "Download")

[maravento]

What would you like

SO Ubuntu 24.04

In the Linux Desktop version, when a file is attached or generated in the chat, the action button on the file widget says "Descargar" (Download). However, in the official Web version, the button says "Abrir" (Open) and allows for a more integrated behavior.

To maintain feature parity and a seamless user experience, the Linux desktop client should mirror the web interface behavior by implementing the "Open" action instead of forcing a download.

Web Version (Expected):

Linux Desktop (Current):

Use case

Aligning this behavior will prevent unnecessary file clutter in the user's download directory. It makes the desktop app feel like a true native extension of the web experience, allowing users to quickly view files without manually navigating their file manager to find where they were saved.

Existing workarounds

Currently, the only workaround is to manually download the file, open the file explorer, find the file, and then open it with an external viewer. Another option is using the web version in a browser instead of this desktop application.

[github-actions]

Automated draft — AI analysis, not maintainer judgment. This bot won't approve enhancements, prioritize roadmap, or commit timelines. The notes below flag existing surfaces and design questions that may be worth considering before implementation.

Looks like the ask is to route the Linux file-attachment button through writeFileDownloadAndOpen (which calls shell.openPath) instead of writeFileDownload (save-only), matching the "Open"/"Abrir" behavior users see on the web.

Existing surfaces worth knowing about:

• writeFileDownloadAndOpen at index.js:445617 already has the full open-after-download path via shell.openPath with a showItemInFolder fallback — the upstream implementation is present; the enhancement likely means wiring the Linux button to invoke this instead of writeFileDownload. (reference-source/.vite/build/index.js:445617-445624)
• writeFileDownload at index.js:445625 is the current Linux-side path — it saves and returns the path with no open step; this is the method the enhancement would replace or bypass. (reference-source/.vite/build/index.js:445625-445627)
• The vr contextBridge object in mainView.js:6397 exposes both writeFileDownload and writeFileDownloadAndOpen to the renderer via separate IPC channels — a patch intercepting which channel the Linux UI calls would likely touch this surface. (reference-source/.vite/build/mainView.js:6397-6411)

Design-review questions:

• Does this change the shape of existing user-facing behavior (flags, paths, environment variables, default state)? If yes, is there a deprecation path for users on the prior behavior?
• Does this widen what the app reads, writes, or executes outside the sandbox? Any new file paths, network endpoints, IPC channels, or shelled-out commands should be named up front.
• When this feature fails for a user, what do they see in --doctor output or ~/.cache/claude-desktop-debian/launcher.log? Silent failure is the default without explicit logging.

Full investigation artifacts attached to the triage workflow run.

---

⚠ This issue was edited after triage began. The
draft above reflects the body as of
2026-06-20T14:07:27Z; the current body may differ.
See input_snapshot.json in the workflow run for
what the bot actually read.

[maravento]

Thanks for the automated analysis! It's great to see that the upstream implementation (writeFileDownloadAndOpen) is already present at index.js:445617.

To answer the design-review questions from a user/system perspective:

1. Behavioral change & deprecation: This doesn't break existing workflows or require a deprecation path. It simply enhances the current Linux button behavior to match the official Web/Windows/macOS client experience (opening the file after downloading it, instead of just saving it silently).
2. Sandbox & Security: It uses the existing writeFileDownloadAndOpen function and the already exposed IPC channels in mainView.js. It does not introduce new network endpoints, external commands, or un-sandboxed paths.
3. Failure handling & Logs: If shell.openPath fails (for instance, if the user lacks a default application configured for that file type), it should gracefully trigger the existing showItemInFolder fallback or log the standard error to ~/.cache/claude-desktop-debian/launcher.log.

This looks like a straightforward IPC channel routing patch. Looking forward to seeing this integrated!