openclaw - 💡(How to fix) Fix claude-max-api-proxy: `messagesToPrompt` stringifies content-block arrays as `[object Object]` (Sonnet/Opus reply with confused 'you sent an object' messages) [1 comments, 2 participants]

Summary

@theserverlessdev/claude-max-api-proxy (the proxy referenced from OpenClaw's claude-max provider docs) has a serialization bug in dist/adapter/openai-to-cli.js:messagesToPrompt. When msg.content is a content-block array (the standard OpenAI/Anthropic multimodal format — [{type:"text", text:"hello"}, ...]), the adapter pushes the array directly to a parts array which is later joined with \n. JavaScript stringifies the array via Array.toString(), calling Object.prototype.toString() on each block, producing the literal string "[object Object]". The model receives [object Object] instead of the actual content and honestly reports "you sent an object, what did you mean?" — which then propagates as conversation history.

End-user symptom: Sonnet/Opus "can't read my messages" but third-party providers (qwen/kimi/deepseek/openrouter) work fine. Bug is invisible from gateway-side trajectory logs because gateway sends correct content; the mangling happens inside the proxy's CLI-input adapter.

Reproduction

1. Install OpenClaw with claude-max provider pointing at claude-max-api-proxy.
2. Issue any request whose messages[].content is an array of blocks (the OpenAI/Anthropic multimodal format), e.g.:

   {
     "model": "claude-sonnet-4",
     "messages": [{"role":"user","content":[{"type":"text","text":"Hello"}]}]
   }

3. Observe Sonnet replying with something like "It looks like you accidentally sent a JavaScript object that got stringified as [object Object]. What did you mean to send?"
4. The same request with content as a plain string works correctly.

Root cause

dist/adapter/openai-to-cli.js:

export function messagesToPrompt(messages) {
    const parts = [];
    for (const msg of messages) {
        switch (msg.role) {
            case "system":
                parts.push(`<system>\n${msg.content}\n</system>\n`);  // ← template-stringifies array as [object Object]...
                break;
            case "user":
                parts.push(msg.content);  // ← pushes raw array; .join() then stringifies each element
                break;
            case "assistant":
                parts.push(`<previous_response>\n${msg.content}\n</previous_response>\n`);  // ← same template-stringify bug
                break;
        }
    }
    return parts.join("\n").trim();
}

Three issues, same shape:

1. ${msg.content} triggers default coercion of arrays/objects to [object Object].
2. parts.push(msg.content) for user role pushes a raw array; parts.join() then coerces each element to [object Object].
3. No content-block awareness anywhere — image/audio/tool blocks are silently dropped or mangled.

Severity

High. Anyone routing OpenAI-style multimodal-format requests through this proxy will get garbage out for Sonnet/Opus. The mangling is invisible from the calling side because the proxy responds with a normal-looking 200 + assistant text — just text that's a confused complaint about [object Object].

Compounding: the assistant's confused-complaint reply gets cached as conversation history and other models reading the history then "confirm" the bug as a real OpenClaw serialization issue, sending users on wild goose chases.

Suggested fix

Add a content-block-aware coercion helper, apply it everywhere msg.content is used:

function contentToString(content) {
    if (typeof content === "string") return content;
    if (content == null) return "";
    if (!Array.isArray(content)) {
        try { return JSON.stringify(content); } catch { return String(content); }
    }
    return content.map((part) => {
        if (typeof part === "string") return part;
        if (part == null) return "";
        if (part.type === "text") return part.text || "";
        if (part.type === "image_url") return "[image]";
        if (part.type === "input_audio") return "[audio]";
        try { return JSON.stringify(part); } catch { return ""; }
    }).filter((s) => s.length).join("\n");
}

export function messagesToPrompt(messages) {
    const parts = [];
    for (const msg of messages) {
        const text = contentToString(msg.content);
        switch (msg.role) {
            case "system":
                parts.push(`<system>\n${text}\n</system>\n`);
                break;
            case "user":
                parts.push(text);
                break;
            case "assistant":
                parts.push(`<previous_response>\n${text}\n</previous_response>\n`);
                break;
        }
    }
    return parts.join("\n").trim();
}

Verification

I applied this patch locally to my own install. Test cases that previously produced [object Object]:

Live test through OpenClaw → claude-max-api-proxy → claude CLI → Sonnet 4.6 / Opus:

• Pre-patch: Sonnet replied "you sent [object Object]" complaints
• Post-patch: clean responses to instructions

Related

• openclaw/openclaw#20566 — claude-max provider serialization error (downstream symptom of this bug)
• Multiple competing proxy forks exist (mattschwen, sethschnrt, rynfar/meridian) — likely all hit the same bug or worked around it differently. Worth coordinating fixes.

Repository

Filing this in openclaw/openclaw because that's where I encountered it through configured documentation. The actual offending package is claude-max-api-proxy (npm, separate repo) — if maintainers want to redirect, happy to refile there.