[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

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

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 SendUserFile from a local git project directory (.md files, ~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):

  1. "File not found" — the URL 404s and nothing is downloadable. Recurring over recent days.
  2. 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.md was offered as pastetochatcaptured1stresstest20260819.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

  1. In a local Claude Code desktop session on Windows, have the agent send a .md file via SendUserFile (attach).
  2. Click the resulting file card in the conversation.
  3. Observe: default browser opens the /api/organizations/{org_id}/files/{file_id}/contents URL; 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

View original on GitHub ↗