[BUG] 400 "text content blocks must be non-empty" when pasting screenshot-only messages
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?
Here's a draft you can paste at https://github.com/anthropics/claude-code/issues/new:
---
Title: 400 "text content blocks must be non-empty" when pasting screenshot-only messages
Body:
Summary
When a message containing only a pasted screenshot (no accompanying text) is sent in Claude Code, the next turn fails with API Error: 400 messages: text content blocks must be non-empty. The error then persists — "Try again" hits the same error because the malformed turn stays in the transcript, effectively wedging the session.
Reproduction
- Open a Claude Code session (desktop app, shared/cowork mode)
- Paste a screenshot into the input with no text
- Send
Expected: Claude responds to the image.
Actual: API Error: 400 messages: text content blocks must be non-empty. "Try again" reproduces the same error. Only workaround is starting a new session.
Environment
- Claude Code desktop app (macOS)
- macOS Darwin 25.3.0
- Model: Opus 4.7 (Max)
- Session type: Shared / cowork (3 repos)
- Session ID:
session_01MPiUjvUmx4jiQdaWA1jrTj
Notes
- Reproduces consistently across multiple sessions whenever a screenshot is shared without accompanying text.
- Workaround: always include at least a few words of text alongside the screenshot.
- Likely cause: client serializes the message with an empty text block alongside the image block; the API rejects empty text blocks.
---
What Should Happen?
Here's a draft you can paste at https://github.com/anthropics/claude-code/issues/new:
---
Title: 400 "text content blocks must be non-empty" when pasting screenshot-only messages
Body:
Summary
When a message containing only a pasted screenshot (no accompanying text) is sent in Claude Code, the next turn fails with API Error: 400 messages: text content blocks must be non-empty. The error then persists — "Try again" hits the same error because the malformed turn stays in the transcript, effectively wedging the session.
Reproduction
- Open a Claude Code session (desktop app, shared/cowork mode)
- Paste a screenshot into the input with no text
- Send
Expected: Claude responds to the image.
Actual: API Error: 400 messages: text content blocks must be non-empty. "Try again" reproduces the same error. Only workaround is starting a new session.
Environment
- Claude Code desktop app (macOS)
- macOS Darwin 25.3.0
- Model: Opus 4.7 (Max)
- Session type: Shared / cowork (3 repos)
- Session ID:
session_01MPiUjvUmx4jiQdaWA1jrTj
Notes
- Reproduces consistently across multiple sessions whenever a screenshot is shared without accompanying text.
- Workaround: always include at least a few words of text alongside the screenshot.
- Likely cause: client serializes the message with an empty text block alongside the image block; the API rejects empty text blocks.
---
Error Messages/Logs
Steps to Reproduce
Here's a revised version with a tight numbered repro:
---
Title: 400 "text content blocks must be non-empty" when sending a screenshot-only message
Summary
Sending a message that contains only a pasted image (no text) in Claude Code causes the next assistant turn to fail with API Error: 400 messages: text content blocks must be non-empty. The error is sticky — clicking "Try again" reproduces it because the malformed turn remains in the transcript — so the session is effectively wedged and must be abandoned.
Steps to reproduce
- Open the Claude Code desktop app on macOS.
- Start a new session in any repo (the bug is not repo-specific; I observed it in a 3-repo cowork/shared session, but a single-repo session reproduces it too).
- Take any screenshot (
Cmd+Shift+4→ drag → release). This places a PNG on the clipboard. - Click into the Claude Code message composer at the bottom of the session.
- Paste with
Cmd+V. The screenshot thumbnail appears in the composer. Do not type any text. - Press
Enter(or click the send button) to submit the message. - Wait for the assistant to respond.
Expected
The assistant receives the image and responds with text describing or acting on what's in the screenshot.
Actual
The assistant turn fails immediately with a red error banner:
API Error
API Error: 400 messages: text content blocks must be non-empty
A "Try again" button is shown. Clicking it reproduces the same error every time, because the malformed user turn is still in the transcript. The session cannot be recovered; the only way forward is to start a new session.
Minimal trigger
No code or files needed beyond a screenshot — any PNG pasted from the clipboard with no accompanying text reproduces it. The exact image content does not matter.
Workaround
Always type at least one character of text alongside the screenshot before sending (e.g. ? or look). With any non-empty text block present, the request succeeds.
Likely cause (best guess from the outside)
When the composer has only an image attachment and no text, the client appears to serialize the user message's content array with both an image block and a text block whose text is "". The Anthropic Messages API rejects empty text blocks with a 400, and since the bad turn is persisted to the transcript, every subsequent retry hits the same validation error.
Environment
- App: Claude Code desktop (macOS)
- OS: macOS, Darwin 25.3.0
- Model: Opus 4.7 (Max tier)
- Session type observed: shared / cowork session across 3 repos
- Affected session ID:
session_01MPiUjvUmx4jiQdaWA1jrTj - Frequency: reproduces 100% of the time on image-only messages
Severity
Medium. Functionality (image input) is broken in a common entry pattern, and there's no in-app recovery once the session is wedged — work continues only by abandoning the session.
---
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.70 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗