openclaw_chat returns 400 Bad Request with local Ollama/Qwen gateway

[ashold12]

Summary

openclaw_chat tool returns 400 Bad Request when called through the MCP bridge. The gateway is healthy, openclaw_instances and openclaw_status work correctly — only openclaw_chat fails.

Environment

Component	Version
openclaw-mcp	v1.3.0 (ghcr.io/freema/openclaw-mcp:latest)
OpenClaw gateway	2026.3.24 (cff6dc9)
Ollama	0.18.3
Model	ollama/qwen2.5:14b (14B, 9.0 GB)
Platform	macOS Darwin x86_64
Client	Claude Code v2.1.85 (MCP over streamable HTTP)

Gateway config (openclaw.json)

chatCompletions endpoint is enabled:

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "auth": { "mode": "token", "token": "REDACTED" },
    "http": {
      "endpoints": {
        "chatCompletions": { "enabled": true }
      }
    }
  }
}

docker-compose.yml

services:
  mcp-bridge:
    image: ghcr.io/freema/openclaw-mcp:latest
    container_name: openclaw-mcp
    environment:
      - OPENCLAW_URL=http://host.docker.internal:18789
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
      - AUTH_ENABLED=true
      - MCP_CLIENT_ID=openclaw
      - MCP_CLIENT_SECRET=${MCP_CLIENT_SECRET}
      - CORS_ORIGINS=https://claude.ai
      - DEBUG=true
    extra_hosts:
      - "host.docker.internal:host-gateway"

Steps to reproduce

1. Start OpenClaw gateway with Ollama/Qwen backend and chatCompletions.enabled: true
2. Start MCP bridge via Docker (config above)
3. Connect Claude Code: claude mcp add --transport http --client-id openclaw --client-secret openclaw http://localhost:3000/mcp
4. Call openclaw_chat with any message

What happens

openclaw_chat(message: "What's your opinion on Pokemon?")
-> Error: API request failed: 400 Bad Request

openclaw_chat(instance: "default", message: "...", session_id: "test")
-> Error: API request failed: 400 Bad Request

openclaw_instances and openclaw_status work correctly — only openclaw_chat fails.

What we know

• Gateway is healthy: /health returns {"ok":true,"status":"live"}

• MCP bridge connects and can list instances

• The chat completions endpoint is enabled in gateway config

• Direct curl to the gateway works fine:

  curl -X POST \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"model":"openclaw","messages":[{"role":"user","content":"hi"}]}' \
    http://localhost:18789/v1/chat/completions
  # -> 200 OK, returns valid chat completion response
  

• The 400 has no detail in bridge logs even with DEBUG=true

What we don't know

We cannot see the actual request the bridge sends to the gateway, so we don't know what's causing the 400. Possible causes:

• Incorrect model name in the request body (gateway requires "openclaw" or "openclaw/agentId")
• Different endpoint path
• Missing or malformed headers
• Auth token not forwarded correctly
• Request body format mismatch

Request

1. Could DEBUG=true log the outgoing request body and the full 400 response body? That would make this trivially diagnosable.
2. Any known compatibility requirements between bridge v1.3.0 and specific OpenClaw gateway versions?
3. Any additional gateway config needed beyond chatCompletions.enabled: true?

[ashold12]

Found the root cause in src/openclaw/client.ts line ~113:

const body: Record<string, unknown> = {
  model: "claude-opus-4-5",  // <-- hardcoded
  messages: [{ role: "user", content: message }],
  max_tokens: 4096,
};

The gateway requires model: "openclaw" (or "openclaw/<agentId>"), but the bridge hardcodes "claude-opus-4-5". This causes every openclaw_chat call to return 400 with:

{"error":{"message":"Invalid model. Use openclaw or openclaw/<agentId>.","type":"invalid_request_error"}}

Suggested fix: change the model to "openclaw" — the gateway routes to whichever model is configured in agents.defaults.model.primary regardless. Or make it configurable via an env var like OPENCLAW_MODEL.

[ashold12]

Additional context: this might be a gateway version issue rather than a pure bug. In an older OpenClaw gateway version, the model field may have been passed through directly to the underlying provider, making "claude-opus-4-5" valid. The current gateway (2026.3.24) validates that model must be "openclaw" or "openclaw/" and uses it as an agent routing key — the actual model is configured server-side in agents.defaults.model.primary. So this may just need updating to match the current gateway API contract.

[freema]

Hey @ashold12, thanks for the detailed report — the root cause analysis in your comment was spot on. This was quite a bit of work to get right so thank you for helping us track it down.

We've prepared a fix in #22. Here's what changed:

Root cause fix:

• Default model changed from claude-opus-4-5 → openclaw
• Model is now configurable via OPENCLAW_MODEL env var or --model CLI flag

Debug logging (your request #1):

• DEBUG=true now actually works (it was documented but never implemented)
• Logs outgoing request bodies and error response bodies (truncated to 4096 chars, credentials redacted)
• Headers are never logged, even in debug mode

Compatibility info (your request #2):

MCP Bridge	Gateway	Result
≤ 1.2.2	≥ 2026.3.24	400 Bad Request — bridge sends wrong model
≥ 1.3.0	≥ 2026.3.24	Works — defaults to openclaw
≥ 1.3.0	older	Works — set OPENCLAW_MODEL to match your gateway

Testing status: I've verified typecheck, lint, unit tests (136 passed), and build — but only partial end-to-end testing. Would you be able to pull the branch and test against your Ollama/Qwen setup? That would give us the confidence to merge and release.

Also heads up: we have the same model field in openclaw-a2a — it's already set to "openclaw" there, but we'll make it configurable via env var as well.

Once you confirm it works, we'll release this as a patch.

[freema]

Update: I've tested this against my own setup and it works correctly. However, I haven't tested with Ollama/Qwen specifically, so @ashold12 — your confirmation would still be valuable before we merge and release.

The same configurability fix has been applied to the A2A bridge as well: freema/openclaw-a2a#1

@ashold12 if you get a chance, it would be great if you could:

1. Pull the fix/21-hardcoded-model-debug-logging branch
2. Test against your Ollama/Qwen gateway
3. Leave a review on fix: configurable model name + debug logging (#21) #22 with the result

This was quite a lot of work to get right across both repos, so thanks again for the thorough issue report — it made the fix much smoother.