[BUG] Desktop app (Windows): delivered file cards open a claude.ai /api/.../files/{id}/contents URL in the browser — 404s or save-as with a corrupted filename
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment
- OS: Windows 11 Pro (10.0.26200)
- App: Claude Code desktop app (Windows), local agent-mode session
- Files delivered by the agent via
SendUserFilefrom a local git project directory (.mdfiles, ~16 KB)
Description
Clicking a delivered file card in the conversation does not handle the file in-app. Instead it opens the file's API URL in the default browser:
https://claude.ai/api/organizations/{org_id}/files/{file_id}/contents
From there, two failure shapes observed across the last several clicks (multiple days):
- "File not found" — the URL 404s and nothing is downloadable. Recurring over recent days.
- Browser save-as with a corrupted suggested filename — two measured instances on 2026-08-19:
- ~08:28 PT: dashes stripped from the name —
paste-to-chat-capture-d1-stress-test-2026-08-19.mdwas offered aspastetochatcaptured1stresstest20260819.md - ~12:35 PT: filename reduced to a single character — the save dialog suggested
%as the entire filename
When the download does succeed, the content is intact — both saved copies were SHA-256-verified byte-identical to the source files on disk. The corruption is in the delivery UX (redirect out of the app + filename loss), not the payload.
Impact
Filename corruption destroys at-a-glance file identity. With multiple similarly-captioned file cards in one conversation, this caused a wrong-file re-upload round trip to another Claude surface before the mix-up was caught. Current workaround: treat cards as decorative — the agent leads every delivery with the real host path, and copies files into Downloads under their correct names itself.
Steps to reproduce
- In a local Claude Code desktop session on Windows, have the agent send a
.mdfile viaSendUserFile(attach). - Click the resulting file card in the conversation.
- Observe: default browser opens the
/api/organizations/{org_id}/files/{file_id}/contentsURL; outcome is either a 404 ("file not found") or a save-as dialog with a corrupted suggested filename.
What Should Happen?
Clicking the card should save/open the file in-app with its original filename — or, for files that already exist on the local host, offer "Show in Explorer" (as requested in #87649). At minimum, the browser redirect should carry a correct Content-Disposition filename.
Related (same family, different variants): #84550 (cards fail to deliver, macOS/Cowork), #86337 (Windows cards open instead of offering download), #86701 (Windows .py downloads fail), #87649 (no Show in Explorer / Copy path on Windows cards). This report adds the browser-redirect + filename-corruption variant on Windows.
🤖 Generated with Claude Code