Once I get an error I can't move on

Description

I asked the model to get some images and perform some actions, it didn't properly get some images so I got this error:

image formats: ['image/jpeg', 'image/png', 'image/gif', 'image/webp'].```

That's fine I replaced the files in the directory with correct working image. But I can't move past the error:

```The image data you provided does not represent a valid image. Please check your input and try again with one of the supported
image formats: ['image/jpeg', 'image/png', 'image/gif', 'image/webp'].

finish task 3 in l9.md and send it to the server
sai (08:01 AM)

The image data you provided does not represent a valid image. Please check your input and try again with one of the supported
image formats: ['image/jpeg', 'image/png', 'image/gif', 'image/webp'].

okay don't use any image
sai (08:01 AM)

The image data you provided does not represent a valid image. Please check your input and try again with one of the supported
image formats: ['image/jpeg', 'image/png', 'image/gif', 'image/webp'].

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

This issue might be a duplicate of existing issues. Please check:

SVG File Paths Rejected #4052: SVG File Paths Rejected - Similar image format validation error preventing task progression
fix: Clipboard image paste fails with AI_DownloadError due to binary corruption and encoding mismatch #3816: Clipboard image paste fails with AI_DownloadError - Related issue with invalid image data handling

Feel free to ignore if your specific case involves different circumstances.

Yeah ill fix this

having the same issue when OC tries to read a big image

It happens to me even without any image provided, no idea where it gets this from.

I've hit this twice so far. Both times it was debugging an issue, not even touching images, then just gets stuck:

Now I have to try and figure what it was doing and convince it to continue in a new thread.

@BASIC-BIT

Any update on this? @BASIC-BIT ?

My current fix is to open a new opencode thread and tell it to remove the b64 image from the history of that current thread. Willing to push a fix, but I frequently run into this problem when using the chrome MCP.

Additional context + reproduction steps

This is a persistent session-poisoning bug. Once an invalid or oversized image gets stored in the message history, every subsequent request in that session fails with the same error — even if you tell the model to ignore images entirely. The bad image data is already baked into the context sent to the API on every turn.

Root cause: OpenCode stores image attachments (base64-encoded) inside the part records in its local SQLite database (~/.local/share/opencode/opencode.db). When the API rejects an image, the offending data remains in the DB and gets replayed on every new message in that session.

Two distinct error variants I've hit:

image exceeds 5 MB maximum: X bytes > 5242880 bytes — full-page screenshots captured via the read tool on binary image files
At least one of the image dimensions exceed max allowed size for many-image requests: 2000 pixels — tall/long screenshots (e.g. full-page captures) where height exceeds 2000px
Steps to reproduce:
In a session, ask the model to take a screenshot or read an image file (e.g. via the read tool on a .png)
If the image is either >5MB or has a dimension >2000px, the API returns a 400 error
Send any follow-up message in the same session — the error repeats identically, regardless of content
Telling the model to "ignore images" or "don't use images" has no effect — the bad attachment is already in the stored history

Workaround (manual DB surgery):

python3 << 'EOF'
import sqlite3, json, base64, struct
conn = sqlite3.connect('~/.local/share/opencode/opencode.db')
cursor = conn.cursor()
# Replace SESSION_ID with your session ID
cursor.execute("SELECT id, data FROM part WHERE session_id = 'SESSION_ID'")
rows = cursor.fetchall()
def get_png_dimensions(b64_data):
    try:
        if ',' in b64_data:
            b64_data = b64_data.split(',', 1)[1]
        raw = base64.b64decode(b64_data[:100])
        if raw[:4] == b'\x89PNG':
            w = struct.unpack('>I', raw[16:20])[0]
            h = struct.unpack('>I', raw[20:24])[0]
            return w, h
    except:
        pass
    return None, None
fixed = 0
for part_id, data_str in rows:
    data = json.loads(data_str)
    state = data.get('state', {})
    attachments = state.get('attachments', [])
    bad = False
    for att in attachments:
        if att.get('mime', '').startswith('image/'):
            url = att.get('url', '')
            b64_size = len(url)
            w, h = get_png_dimensions(url)
            if b64_size > 5_000_000 or (w and (w > 2000 or h > 2000)):
                bad = True
                break
    if bad:
        data['state']['attachments'] = []
        cursor.execute("UPDATE part SET data = ? WHERE id = ?", (json.dumps(data), part_id))
        fixed += 1
conn.commit()
print(f"Stripped {fixed} bad image(s)")
conn.close()
EOF

Expected behavior: The session should either (a) not store image attachments that exceed API limits in the first place, or (b) gracefully strip/skip bad attachments from history on retry rather than hard-failing every subsequent turn.

fix(session): sanitize image attachments before sending to API

@rekram1-node

@rekram1-node Did you end up fixing this? If not, see my related PR.

@kozak-codes

This bug has several duplicate/related issues open:

Request Entity Too Large with images blocks session — compaction also fails #14562 -- best root cause analysis, covers the compaction failure path
Session becomes permanently dead when image exceeds provider size limit — no recovery possible #21668 -- session permanently dead, no recovery
Images exceeding 2000px are rejected by Anthropic API #12068 -- 2000px dimension rejection
request_too_large: Request exceeds the maximum size // exceded pixels image #13865 -- request_too_large variant

The root cause is the same across all of them: oversized or invalid image data gets persisted in session history as base64 data URLs. Every subsequent API call replays the bad image, the provider rejects it, and the session is permanently stuck. Compaction can't help because it also replays the images (or has nothing to compact if it's early in the session).

There are two open PRs:

fix(session): sanitize image attachments before sending to API #19555 by @kozak-codes: validates images in transform.ts before sending (checks MIME type, 5 MB size, 2000px dimensions). Replaces bad images with descriptive error text. No new dependencies, 6 new tests, all CI green. Waiting on maintainer review since March 28.
fix: resize images before sending to Anthropic API #12069 by @coleleavitt: resizes images via sharp before sending. More complete UX (images work instead of erroring) but CI is failing and adds a native dependency.

#19555 is the simplest path to stop sessions from bricking. Image resizing could be a follow-up.

We have several people on our team hitting this regularly. It kills active sessions mid-task with no recovery path other than manual SQLite surgery or starting over. Would be great to get a maintainer review on #19555.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

I just hit this issue.

Navigation Menu

Repository navigation

Once I get an error I can't move on #4781

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Once I get an error I can't move on #4781

Description

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Nov 26, 2025

rekram1-node commented on Nov 26, 2025

luisrudge commented on Jan 7, 2026

vaisov commented on Jan 26, 2026

rosspeoples commented on Feb 20, 2026

kozak-codes commented on Mar 28, 2026

kozak-codes commented on Mar 28, 2026

kozak-codes commented on Mar 28, 2026

zeke commented on Apr 10, 2026

github-actions commented on Jul 3, 2026

infomiho commented on Aug 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions