[BUG] Image upload fails with "Failed to fetch" — regression in 2.1.209 (macOS Desktop/Cowork)

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?

Image uploads in Claude Desktop / Cowork stopped working after the app updated this morning (2026-07-16). The same screenshots uploaded fine yesterday on the previous build.

The UI first shows:

Server is busy. Retrying in 6s (attempt 5 of 10)

and eventually fails with:

Failed to upload "<filename>.png". The file format may not be supported or the file may be corrupted.

The "Server is busy" message appears to be misleading — this does not look like a capacity issue:

• status.claude.com shows all systems operational
• Text-only messages work fine on the same connection
• Reproducible on two completely different networks (Starlink and a mobile carrier), which rules out a local connectivity problem
• The file is a valid, ordinary macOS screenshot PNG

The retry wrapper masks whatever the real error is, so the message sends users chasing network/capacity problems that don't exist.

What Should Happen?

Screenshots attach and upload successfully, as they did on the previous build.

Additionally: when an upload does fail, the UI should surface the actual underlying error rather than a generic "Server is busy. Retrying (attempt N of 10)" message, which points users at the wrong cause.

Error Messages/Logs

--- UI (visible to user) ---
Server is busy. Retrying in 6s (attempt 5 of 10)
Failed to upload "Снимок экрана 2026-07-16 в 12.12.08.png". The file format may not be supported or the file may be corrupted.

--- ~/Library/Logs/Claude/claude.ai-web.log ---
2026-07-16 12:23:58 [error] [REACT_QUERY_CLIENT] QueryClient error: {"name":"TypeError","message":"Failed to fetch","stack":"TypeError: Failed to fetch\n    at s (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/c26148d62-BzytMXXj.js:2:25336)\n    at https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/c26148d62-BzytMXXj.js:3:82493\n    at https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/c26148d62-BzytMXXj.js:3:82741\n    at ZT (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/c26148d62-BzytMXXj.js:3:85794)\n    at https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/c26148d62-BzytMXXj.js:3:87025\n    at async h (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/vendor-query-w8ME5CaM.js:1:17556)\n    at async Object.c [as fn] (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/vendor-query-w8ME5CaM.js:1:17853)"}

Note: `TypeError: Failed to fetch` means the request was aborted before any HTTP status came back. No 4xx/5xx is logged anywhere in any log file.

--- ~/Library/Logs/Claude/main.log (message dispatch itself looks healthy) ---
2026-07-16 12:53:32 [info] LocalAgentModeSessions.sendMessage: sessionId=local_1649a03c-..., messageLength=0, imageCount=2, fileCount=0, widgetStates=0, contentBlocks=0
2026-07-16 12:53:32 [info] [Lifecycle] Session local_1649a03c-...: idle → initializing
2026-07-16 12:53:32 [info] [oauth] using cached token for orgId=...
2026-07-16 12:53:32 [info] [Lifecycle] Session local_1649a03c-...: initializing → running

OAuth scopes in use: user:inference user:file_upload user:profile

The session starts and /v1/messages dispatches normally — the failure appears isolated to the file-upload path, not inference.

Steps to Reproduce

1. Update Claude Desktop to the build shipped on 2026-07-16 (bundled claude-code 2.1.209).
2. Take a standard macOS screenshot (Cmd+Shift+4). Default filename contains non-ASCII characters and spaces, e.g. Снимок экрана 2026-07-16 в 12.12.08.png.
3. Attach it to a chat in Claude Desktop (Cowork session).
4. Observe Server is busy. Retrying in 6s (attempt N of 10), followed by Failed to upload ... The file format may not be supported or the file may be corrupted.

Text-only messages in the same session work normally. The same screenshot uploaded successfully on the previous build (2026-07-15).

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.209

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Surface: Claude Desktop for macOS (Cowork session), not the CLI — the "Terminal/Shell" field is set to "Other" because no terminal is involved. Model in use was claude-fable-5 (per main.log), which isn't offered in the Claude Model dropdown, hence "Other".

Not a network problem. Ruled out over several hours:

• Reproduces identically on Starlink and on a mobile carrier connection
• Text-only messages in the same session work fine
• No 4xx/5xx anywhere in any log — the fetch aborts before a status is returned
• status.claude.com reported all systems operational throughout

Two competing hypotheses — neither confirmed. Flagging both so this doesn't get chased down one path:

1. File size threshold. #41242 documents a size-dependent upload failure on Claude Desktop (28KB PNG succeeds, 70KB PNG fails with "Upload failed due to a network issue") that was characterised as server/edge-side. In my case a small PNG uploaded successfully in the same session while a full-resolution macOS screenshot consistently failed. That is consistent with a size threshold.
2. Filename encoding. The failing file is a macOS screenshot whose default filename contains Cyrillic characters and spaces (Снимок экрана 2026-07-16 в 12.12.08.png). The successful file had a short ASCII name. That is equally consistent with a multipart filename-encoding problem.

The two are confounded in my testing (the small file was also the ASCII-named one), so I can't yet separate them. Happy to run a controlled test — same file, renamed to ASCII vs. downscaled — if that's useful.

Prior art worth cross-referencing: #41242 (size-dependent upload failure, closed as not planned), #44856 (Cowork Windows screenshot uploads, closed as dup), #39580 (API 400 on multi-image paste), #39539 (Dispatch photo uploads fail silently). Those are Windows/March and this is macOS/July after a specific build update, so I've filed separately rather than commenting there — but if the upload pipeline is the common factor, they may share a root cause.

Main ask beyond the fix: the Server is busy. Retrying in 6s (attempt 5 of 10) wrapper actively misleads. It reports a server capacity problem when the failure is in the upload path. Hours went into chasing CGNAT timeouts, IPv6 routing and upload bandwidth before the real error surfaced — and looking at the issues above, other people have burned time the same way. Propagating the underlying error to the UI would prevent a lot of misdirected debugging.

Environment:

• Claude Desktop (Cowork), bundled claude-code 2.1.209
• macOS, Apple Silicon, 24 GB RAM
• Last working build: the one shipped on 2026-07-15 (exact version not recorded — auto-updated overnight)