Skip to content

[Bug]: mcode acp cannot accept image content in session/prompt. The agent rejects image blocks at the protocol layer, even though both the configured model and the interactive CLI support image input. #479

Description

@BasuruK

Product or interface

CLI - ACP

Version

0.6.8

Platform

macOS

OS version and architecture

27.0.1

Issue area

Startup / install / update

Desktop log upload ID (optional)

No response

Steps to reproduce

Reproduce with raw JSON-RPC over stdio, no host required.

1. Handshake. Confirm what the agent advertises:

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{"fs":{"readTextFile":false,"writeTextFile":false}},"clientInfo":{"name":"probe","version":"0.0.1"}}}' | mcode acp

Observed initialize result (capabilities abridged):

{
  "protocolVersion": 1,
  "agentCapabilities": {
    "loadSession": true,
    "mcpCapabilities": { "http": true, "sse": true },
    "promptCapabilities": {
      "image": false,
      "audio": false,
      "embeddedContext": false
    },
    "sessionCapabilities": {
      "list": {}, "fork": {}, "resume": {}, "close": {}
    }
  },
  "agentInfo": { "name": "minimax-code", "title": "MiniMax Code", "version": "0.6.8" }
}

2. Create a session:

{"jsonrpc":"2.0","id":2,"method":"session/new","params":{"cwd":"/tmp","mcpServers":[]}}

3. Send a prompt containing one text block and one image block:

{"jsonrpc":"2.0","id":3,"method":"session/prompt","params":{
  "sessionId":"<sessionId>",
  "prompt":[
    {"type":"text","text":"Reply with the single word OK."},
    {"type":"image","mimeType":"image/png","data":"<base64 png>"}
  ]
}}

Session creation succeeds. The prompt is rejected. Any number of images behaves
identically.

The rejection happens before decoding — a valid 1x1 PNG is enough to trigger it.

Expected and actual behavior

Expected: Given a model whose configuration declares attachment: true with
input modalities text, image, video, and max_image_bytes_inline of 10485760,
the ACP transport should carry image content blocks and report
promptCapabilities.image: true.

Actual: Two layers agree on refusing, so the failure is consistent ratherthan a mis-negotiated flag:

  1. initialize advertises promptCapabilities.image: false.
  2. session/prompt hard-rejects an image block with JSON-RPC -32602.

Relevant model configuration, for contrast:

MiniMax-M3.1-Flash-Preview:
  attachment: true
  modalities.input: [text, image, video]
  limit.max_image_bytes_inline: 10485760

So the capability exists at the model layer and in the CLI surface, and is
absent only in the ACP transport.

Redacted error summary

Protocol layer, from the `session/prompt` response:


{"jsonrpc":"2.0","id":3,"error":{"code":-32602,"message":"Invalid params: Prompt content type image is not supported in ACP P0."}}


Observed downstream in an ACP host that gates on the advertised capability. The
host refuses to dispatch the turn and surfaces a generic failure to the user,
with no indication that the attachment was the cause:


ProviderAdapterProtocolError: ACP driver did not negotiate image prompt support.


The failed turn never reaches the agent: no `session/prompt` request is emitted,
and the run terminates immediately after start.

## Impact

- A host that respects `promptCapabilities.image` cannot send images, by design.
- A host that sends them anyway gets an opaque `-32602` instead of a
  capability-level refusal.
- Users get a generic "provider failed to start" message with no actionable
  detail, which is the hardest version of this to diagnose.

## Notes

The error string suggests images are deferred by an explicit "ACP P0" scope
decision rather than an oversight. If that is intentional, the capability is
reported correctly and this is a feature request for image parity in ACP. If
image support is expected to ship in this transport, then both the advertised
capability and the prompt handler need to move together.

`embeddedContext` and `audio` report `false` in the same way.

Screenshots

Image

Before submitting

  • I have searched existing issues.
  • I have included my version and removed sensitive information.

Activity

  1. added
    bugSomething isn't working
    needs-triageAwaiting maintainer assessment
    on Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingneeds-triageAwaiting maintainer assessment

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions