Repository navigation
[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
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 acpObserved 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:
initializeadvertisespromptCapabilities.image: false.session/prompthard-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
Before submitting
- I have searched existing issues.
- I have included my version and removed sensitive information.
Activity