[Bug]: HEIC photos not rendered in Desktop app

[carlosbaraza]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Upload some pictures from your iPhone.

Expected behavior

Render correctly the images

Actual behavior

On Desktop you get this.

Impact

Major degradation or frequent failure

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Thanks for the screenshot — this is a real Desktop preview bug, not the older “Claude rejected HEIC and killed the turn” reports.

The grid is the user-message attachment gallery in MessagesTimeline (<img src={previewUrl}>). Those eight files are still named IMG_*.heic, and Chromium/Electron cannot decode HEIC, so you get the broken-image icon. Safari/iOS can decode HEIC, which is why this shows up as “works on the phone, broken on Desktop.”

#8161 already converts HEIC→JPEG when you attach in the web/desktop composer (and renames to .jpg). It does not decode HEIC when rendering an attachment that was already stored as HEIC. Workspace image preview also does not treat .heic/.heif as previewable.

So this is distinct from:

• #7225 / #4579 — provider rejection / wedged turn (closed)
• #8161 — attach-time conversion only

Likely cases for .heic names still appearing

1. Photos uploaded from iPhone (mobile or an older desktop) and then viewed in the Desktop app
2. A Desktop build from before feat(web): safely attach HEIC photos as JPEG images #8161
3. Any other path that persists image/heic (the attachment schema allows any image/*; the server still knows the .heic extension)

Fix direction: decode HEIC on the web/desktop render path (timeline, lightbox, composer thumbs) — reuse heic-to or transcode when serving the attachment — so existing HEIC previews work even when attach conversion never ran.

If you have it, a Desktop version/commit and whether you attached on Desktop vs opened a thread that was uploaded from iPhone would pin down which inbound path stored the HEIC. Not required to treat this as accepted.