Summary

On the Linux x86_64 prebuilt binary of opencode 1.14.48, every image attachment — both Read-tool results and user-message attachments via @path — gets stripped with the message:

[N image(s) omitted: could not be resized below the inline image size limit.]

regardless of the image's actual size or dimensions. A 215-byte 100×100 PNG triggers the same omission as a multi-MB screenshot. The same opencode version on macOS arm64 handles the exact same images correctly.

Reproduction

# On Linux x86_64, opencode 1.14.48
python3 -c "from PIL import Image; Image.new('RGB',(100,100),'red').save('/tmp/tiny.png','PNG',optimize=True)"
ls -la /tmp/tiny.png   # ~215 bytes

Then in an opencode session, ask the agent to read it. The tool returns the omission message; the model never sees pixels.

Same .png, same opencode version on macOS arm64 — model sees it.

Root cause (from binary inspection)

The Read tool itself is fine — it produces correctly-formatted data:image/png;base64,... URLs in the attachment. The failure is in Image.normalize:

let e = yield* n.cached(n.promise(async () => {
    try {
        let i = (await import("/$bunfs/root/chunk-9xcfc9am.js", {with:{type:"file"}})).default;
        globalThis.__OPENCODE_PHOTON_WASM_PATH = i;
        return await import("/$bunfs/root/chunk-t7x3896v.js");
    } catch {
        return null;
    }
}))

On Linux x86_64, this import resolves to null (the try/catch swallows whatever the underlying Bun WASM load error is). Then in normalize:

let d = yield* e;
if (!d) return yield* new _y;   // PhotonUnavailableError

Every image throws PhotonUnavailableError. Upstream in the session processor's tool-result handler:

case "tool-result": {
  let Z = attachments.filter(H => H.mime.startsWith("image/")),
      F = yield* forEach(Z, H => Image.normalize(H).pipe(exit)),
      E = F.filter(isFailure).length;
  N = {
    output: E === 0 ? output : `${output}

[${E} image${E===1?"":"s"} omitted: could not be resized below the inline image size limit.]`,
    attachments: successful_ones
  };
}

The user-facing string is hardcoded and does not distinguish between the three real error classes (PhotonUnavailableError, ImageInvalidDataUrlError, ImageDecodeError, ImageSizeError). All four collapse into the same misleading "could not be resized below the inline image size limit" message.

Environment

• opencode 1.14.48 (install script, single-binary)
• file /home/.../.opencode/bin/opencode → ELF 64-bit LSB executable, x86-64, dynamically linked, GNU/Linux 3.2.0
• Ubuntu 24.04, kernel 6.17 generic
• Provider: anthropic via opencode-claude-auth@1.5.0 plugin
• Model: anthropic/claude-opus-4-7 (also confirmed broken with other Anthropic models)

Working comparison: same opencode version, same plugin, same model, but on macOS arm64 — works perfectly.

Suggested fixes (in order of value)

1. Fix Photon WASM load on Linux x86_64. The try/catch { return null } should at minimum log the underlying error so users have a chance to diagnose. Ideally the WASM bundling should work on Linux as it does on macOS — most likely a Bun import('/$bunfs/...', {with:{type:'file'}}) quirk that differs by platform.
2. Stop masking distinct errors behind a misleading message. PhotonUnavailableError, InvalidDataUrlError, DecodeError, and SizeError are very different conditions. A user seeing "could not be resized below the inline image size limit" has no reason to suspect a WASM loader failure on their host platform. At minimum the four error classes should produce four distinct user-facing strings.
3. Graceful degradation — if the Photon WASM is unavailable but the image already fits within the configured max_* limits (which an unresized 100×100 215-byte PNG trivially does), just pass it through without normalization. The current pipeline rejects everything, even images that don't need resizing.

Happy to test a candidate fix on this same Linux setup.