Desktop (Windows): SendUserFile card renders but is inert on engine <=2.1.237; works on 2.1.241 — behavior differs between concurrently-open sessions

Summary

On the Windows desktop app, SendUserFile renders a file card that looks correct but does nothing when clicked — no preview, no open, no download, no error. The card is inert.

The failure correlates with the engine version pinned at session start, not with the file, the tool call, or the client. Because a long-running session keeps the engine it started with, the user can have several sessions open side by side where some file cards work and others are dead, with nothing in the UI to explain the difference. That inconsistency is what made this hard to report — it reads as random.

Related but distinct: #88889 is the terminal CLI on macOS rendering nothing. Here the card renders and is simply not actionable.

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| App package | Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (MSIX) |
| Client | desktop app (entrypoint: claude-desktop, kind: interactive for every session below) |
| Engine | varies per session — see table |

⚠️ claude --version reports 2.1.238 on this machine while the session actually runs 2.1.241 (read from the version field of live transcript records). The per-record version is the number used throughout this report. Same measurement trap noted in #87694.

Evidence

Six user complaints about dead cards were located by scanning transcripts, then correlated with the SendUserFile call immediately preceding each one and with the engine version at that moment. 198 SendUserFile calls were examined in total.

| Date (KST) | Session | File type | display | Engine | Card |
|---|---|---|---|---|---|
| 2026-08-05 | fe9f8516 | .md | (omitted) | 2.1.221 | dead |
| 2026-08-17 | 526946f1 | .xlsx | attach | 2.1.229 | dead |
| 2026-08-23 | dc8375b0 | .md | attach | 2.1.237 | dead |
| 2026-08-23 | a6b0b8b1 | .png | render | 2.1.237 | dead |
| 2026-08-25 | 041b0d98 | .png | render | 2.1.237 | dead |
| 2026-08-26 | e7c8e262 | .html | render | 2.1.237 | dead |
| 2026-08-26 | dc8375b0 | .md ×2 | render | 2.1.241 | works |

dc8375b0 is the same session in two rows — it upgraded 2.1.237 → 2.1.241 at 2026-08-26T01:55 mid-session. The card that was dead on 08-23 works on 08-26 in that same session.

Ruled out

• File type — .md, .xlsx, .png, .html all failed. Images fail too, so it is not "only non-previewable types".
• display parameter — omitted, attach, and render all failed on 2.1.237.
• File existence — the failing files existed on disk at the time of the click (verified for the 08-26 case, complained about 6 minutes after the send).
• File location — controlled A/B on 2.1.241: identical .md content sent from (A) inside the session cwd and (B) the session scratchpad under %LOCALAPPDATA%\Temp\claude\.... Both opened. Location made no difference.

Steps to reproduce

1. Open a desktop session running engine ≤ 2.1.237 (a session started before the 2.1.24x rollout will still be on it — check the version field in its transcript, not claude --version).
2. Have Claude call SendUserFile with any local file.
3. The card renders with the correct name, type badge, and size.
4. Click it — nothing happens.
5. Open a session on 2.1.241 and repeat: the card opens normally.

Expected

Either the card opens, or it visibly indicates why it cannot.

Impact

This is worse than a plain broken feature because it is silent on both ends. The tool returns N files delivered to user., so the model believes delivery succeeded and moves on, often saying "see the attached file". The user sees a card that looks clickable and is not. In this case that loop repeated across three weeks and six separate complaints before the cause was found, because each occurrence looked like a one-off and the same action worked in a neighbouring session.

Requests

1. Confirm which build fixed this, so users still on an older engine know to restart rather than keep filing one-off reports. If it was not fixed deliberately, it may be at risk of regressing.
2. Surface the running engine version per session in the UI. Engine version is pinned at session start, so concurrently-open sessions can behave differently with no visible cause. Today the only reliable way to read it is parsing transcript JSONL. claude --version does not match.
3. Consider making SendUserFile report an actionable delivery result. A success string that is returned when the card cannot be opened gives the model no way to detect the failure and fall back (e.g. to pasting the content inline).