Repository navigation
[Bug]: Save image fails with a CORS error while the viewer is showing the picture #26913
Description
Area
apps/desktop
Steps to reproduce
- In the macOS desktop app, open an image in the viewer. The image is served over HTTPS by a host that does not send
Access-Control-Allow-Origin. A private host is enough. The picture renders in the viewer. - Save that image from the viewer.
Expected behavior
The image saves. It is already on screen, so saving should not depend on the host sending CORS headers.
Actual behavior
A toast appears:
Could not save image
The file could not be fetched. The host may block browser access (CORS), or the connection may be unavailable.
The viewer keeps showing the picture. Nothing is saved.
An img can display a cross-origin image without CORS. Saving fetches the bytes in the renderer, and the browser blocks that read when the host sends no CORS headers.
Impact
Minor bug or occasional failure
Version or commit
Desktop app (Beta) on macOS, paired to a remote environment running t3 v0.1.1.
Environment
macOS, T3 Code desktop (Beta). Remote environment: t3 v0.1.1.
Logs or stack traces
No stack trace. The toast is the only error.
Screenshots
Account names, project names, and the picture itself are removed. The viewer frame and the toast are unchanged.
The viewer shows the picture:
Save then fails:
Workaround
Open the image URL in a normal browser on a machine that can reach the host, and save it from there.
Related
#21367 (open) routes desktop Save through webContents.downloadURL, which does not depend on renderer CORS. #23084 covers Copy. #23619 is the separate data: URL case. This report is Save of an HTTPS image that is already visible in the viewer.
Activity
ray-filet commentedon Oct 30, 2026
Same toast on a local server that does send CORS headers, so this isn't limited to hosts without CORS.
Environment
http://127.0.0.1:37730.1.6-nightly.20261030.3917(server and app)Steps to reproduce
~/.t3/notes/...). The images show in the chat.Actual behavior
"Could not save image. The file could not be fetched. The host may block browser access (CORS), or the connection may be unavailable." The second image fails the same way.
Evidence
assets.createUrl→AssetAccess.resolveAsset→assetFileResponseinserver.trace.ndjson, all successful.desktop:context-menuspans at 21:27:25, 21:27:34, 21:28:51) produced noresolveAssetorassetFileResponsespans. The renderer'sfetch()inreadMediaBlob(apps/web/src/components/media/mediaContent.ts) threw before the request reached the server./api/assets/*on this server returnsaccess-control-allow-origin: *, checked withcurl -H 'Origin: t3code://app'. The desktop CSPconnect-srcallowshttp:. So the CORS wording in the toast is misleading here, and the root cause in the renderer is unconfirmed.Workaround
Open the file from disk. The viewer path is the local file.
#21367 (routing desktop Save through
webContents.downloadURL) would likely cover this case too, since it bypasses the rendererfetch().Triaged with
t3 triageby Claude Code (Opus 5.5,claude-opus-5-5).