[BUG] Cowork: Outputs file download fails with 404 when the filename matches a Project doc name

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?

In a Cowork session that belongs to a Project, downloading a file from the Outputs panel fails if the file name is identical to the name of a document already stored in that Project's knowledge.

The client requests the file with a project:// path instead of the session file path, and the endpoint returns 404. The desktop app shows "Unable to open file.", the web app shows the toast "Failed to download files".

The failure is name-based only. The very same bytes download successfully as soon as the file is renamed to something that does not collide with any Project doc.

This is specific to Cowork. In regular Chat mode inside the same Project, a document created with the same name is saved and downloaded without any problem.

What Should Happen?

The file produced by the Cowork session should download to disk, regardless of whether a Project knowledge document happens to have the same file name. Outputs entries should resolve to the session file, not to a Project document.

Error Messages/Logs

Network request made by the client when clicking Download:

GET /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file?path=project%3A%2F%2F01-%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%BA%D0%B0-kwork.md
→ 404

Decoded value of the `path` query parameter:
project://01-механика-kwork.md

Desktop app log, ~/Library/Logs/Claude/main.log
Note: the query string is not logged, only the path, which makes this
impossible to diagnose from logs alone.

2026-09-01 17:41:22 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-01 17:41:27 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-02 17:58:21 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-02 18:41:36 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-03 16:03:41 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-03 16:03:50 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-03 16:05:12 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-03 16:05:49 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file

A/B contrast from the same log within the same minute. Successful downloads
are logged as "[download] applied web-origin mark", failures as
"fetchToDownloads: 404":

2026-09-03 16:16:34 [info] [download] applied web-origin mark { mark: 'quarantine-xattr', surface: 'spa-fetch' }
2026-09-03 16:16:43 [info] [download] applied web-origin mark { mark: 'quarantine-xattr', surface: 'spa-fetch' }
2026-09-03 16:16:50 [error] fetchToDownloads: 404  for /api/organizations/3768180a-67f2-43cb-b159-9c987122c333/cowork/sessions/cse_01CtNc8giV92w2V6QEXSeUha/download-file
2026-09-03 16:24:02 [info] [download] applied web-origin mark { mark: 'quarantine-xattr', surface: 'spa-fetch' }
2026-09-03 16:24:10 [info] [download] applied web-origin mark { mark: 'quarantine-xattr', surface: 'spa-fetch' }

The three "applied web-origin mark" entries at 16:16:34, 16:16:43 and the two
at 16:24 are files whose names do not collide with any Project document.
The 404 at 16:16:50 is a file whose name matches a Project document.
The 16:24 pair is the exact same content as the failing files, only renamed.

Steps to Reproduce

1. Create a Project and add a document to its knowledge, for example 01-notes.md.
2. Start a Cowork session inside that Project.
3. Ask Claude to create a file with the exact same name, 01-notes.md, and deliver it to the conversation. It appears in the Outputs panel.
4. Open the file in the preview panel. The content renders correctly, so the file exists and is readable.
5. Click Download.
6. Observe the failure: "Unable to open file." in the desktop app, "Failed to download files" in the web app.
7. Now ask Claude to deliver the identical content under a different name, for example 01-notes-v2.md.
8. Click Download on the new file. It downloads successfully.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.44121.2 (Claude Desktop app for macOS, not the CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Notes on the form fields above: this is a bug in the Claude Desktop app (Cowork), not in the Claude Code CLI, so "Claude Code Version" holds the desktop app version and "Terminal/Shell" is not applicable.

Reproduced on desktop app 1.40609.0 (first occurrence 2026-09-01) and on 1.44121.2 (2026-09-03), macOS arm64, Electron 42.10.0, Node 24.18.1. Also reproduced in the web app in Safari, so it is not desktop-only.

Ruled out:

• Not caused by non-ASCII file names. A pure ASCII file download-test-latin.md with no name collision downloads fine, and a Cyrillic-named file with no collision also downloads fine.
• Not caused by content or size. The same bytes download once renamed.
• Not a Project knowledge problem. The documents are intact and render fully both in the Project panel and in the Cowork preview panel.

Suggested fix directions:

1. Resolve Outputs entries by session file path rather than by matching the file name against Project knowledge.
2. If a project:// URI is intentional here, make the download-file endpoint able to serve it.
3. Log the full request URL including the query string on fetchToDownloads errors. Right now the log line omits the path parameter, which is the only thing that reveals the cause.

Workaround: give the output file a name that does not match any document in the Project.

Related issues

Searched for duplicates, none of the following describe this mechanism:

• #84550 — same symptom and same "Unable to open file" toast in Cowork on macOS, but the stated cause is a file card pointing at a session VM path that stops existing after the VM shuts down. No mention of Project doc name collision, project:// paths or a 404 on download-file.
• #85966 — Cowork Outputs panel cannot open or save files, Windows MSIX only, caused by file locks around MSIX updates. It does also report the preview rendering correctly while saving fails.
• #86701 and #88229 — same toast text, but caused by executable-extension download filters, not by file naming.

No open issue mentions fetchToDownloads, project:// or a 404 on the Cowork download-file endpoint.

<img width="310" height="52" alt="Image" src="https://github.com/user-attachments/assets/87c6c733-5a88-44ad-bd4b-a4f5374a05e2" />