Tool-returned PNG causes persistent Bedrock image-input errors and blocks session continuation #14493

Description

An agent called the built-in read tool on a PNG. The tool completed successfully and stored an image/png attachment. The next model request failed because Amazon Bedrock rejected image input. A later request in the same session failed identically while the attachment remained in history.

This leaves the conversation blocked by an attachment introduced by the agent itself. Rewinding to an earlier user message can discard substantial conversation and workspace changes. Recovery should not require a conversation rewind or direct database repair.

Expected behavior: avoid sending image attachments when the selected model/provider cannot accept them, and recover from an image-input rejection while preserving the conversation and workspace. A rejected image should be represented to the model as a clear text-only error rather than silently claimed to have been inspected.

Plugins

Not isolated. No minimal plugin-free reproduction has been run.

Kilo version

7.7.7, confirmed in the affected stored session and installed CLI.

Steps to reproduce

Observed sequence in a real VS Code session, not yet independently reproduced in a fresh session:

1. Use amazon-bedrock/us.openai.gpt-6-astra through the Bedrock converse-stream endpoint in us-east-1.
2. Let the agent invoke the built-in read tool on a local PNG.
3. The tool completes and returns one image/png attachment.
4. The next model request fails with HTTP 400 and AWS ValidationException.
5. Send another message in the same session. The same rejection occurs with the image still in history.

Displayed error:

undefined: This model doesn't support the image field for user messages. Remove image and try again.

AWS response body:

{"message":"This model doesn't support the image field for user messages. Remove image and try again."}

The first recorded failure occurred on 2026-09-23 at 09:39:17 UTC, immediately after the PNG read. Another request failed identically at 09:46:48 UTC. Both selected the same Bedrock model. The undefined: prefix was absent from the AWS response body and was introduced by client or SDK error handling.

Recovery and evidence limits

After backing up the session, we removed only the image attachment from the completed tool result. Comparison against the backup confirmed all 131 messages and 544 history entries remained, with no other tool results or session settings changed. No workspace files were modified by that repair.

A successful post-repair provider request has not been verified. We have not established whether the underlying rejection is caused by provider request conversion or a Bedrock model limitation. This report does not claim that Astra lacks image support on every provider.

The installed CLI resolves this model with capabilities.input.image: true, so a capability check alone will not prevent this failure. Source inspection found that supportsMediaInToolResult() in packages/opencode/src/session/message-v2.ts accepts image attachments for every direct Bedrock model, while unsupportedParts() in packages/opencode/src/provider/transform.ts checks user-message media rather than media inside tool results.

Related reports

• Custom provider model ignores modalities config - image input blocked #10894 and Vision-capable models are incorrectly reported as not supporting image input #8819 concern the opposite capability-detection failure: Kilo blocks images that the model supports. Both are closed for inactivity.
• Encoded images can collapse the dynamic output token allowance #11432 concerns image history reducing the output token allowance, not unsupported image input.

Searches of open and closed issues found no exact duplicate of this persistent Bedrock rejection after a tool-returned image.

Screenshot and/or share link

Not shared. The report intentionally excludes image contents, private filenames, local paths, and session transcripts.

Operating System

macOS

Terminal

VS Code extension session.