Provider 400 after successful Bash output with zgo@kimi-k2.5/k2.6 in Claude Code v2.1.119

[yowmamasita]

Summary

When running claudish with ZenGo Kimi models, tool execution can succeed (and print output) but the provider layer still returns:

{"type":"error","error":{"type":"invalid_request_error","message":"Error from provider: Provider returned error"}}

This appears after Bash tool calls in claudish --model zgo@kimi-k2.5 and claudish --model zgo@kimi-k2.6.

Environment

• claudish CLI (Claude Code banner shows v2.1.119)
• Models:
  • zgo@kimi-k2.5
  • zgo@kimi-k2.6

Reproduction

1. Run:

   claudish --model zgo@kimi-k2.5

   or

   claudish --model zgo@kimi-k2.6

2. Prompt:

   show me offline clients
   

3. Agent executes a Bash tool command.

Observed behavior

k2.5

• First attempt (ssh ...) fails auth (expected for missing creds)
• Second attempt with sshpass returns valid table output (38+ lines)
• Despite successful command output, UI shows API error:
  • invalid_request_error: Error from provider: Provider returned error

k2.6

• Sometimes gets stuck in repeated Coalescing…
• When it does run Bash, same API Error: 400 appears after command output/failure

Expected behavior

• If Bash output is valid and returned, the turn should complete normally.
• Provider errors should not be surfaced when the tool result is already available and usable.

Additional context

Potentially relevant code path:

• packages/cli/src/providers/probe-live.ts line ~314

• claudish/packages/cli/src/providers/probe-live.ts

  Line 314 in a944199

  "provider returned error event";

Raw snippets

⎿  API Error: 400
{"type":"error","error":{"type":"invalid_request_error","message":"Error from provider: Provider returned error"}}

k2.6 session also showed repeated: "Coalescing…"

[claudish-bot]

@yowmamasita Quick correction on the pointer: probe-live.ts:314 is the --probe health check's fallback label ("provider returned error event") — different string, different path. The "Error from provider: Provider returned error" text isn't anywhere in claudish; it's coming back from OpenCode Zen Go upstream and getting passed through by ensureAnthropicErrorFormat in handlers/shared/anthropic-error.ts.

Where it routes:

• zgo@kimi-k2.5/k2.6 → openCodeZenProfile in providers/provider-profiles.ts:189
• Non-minimax, non-gpt-* models take the OpenAIAPIFormat + /v1/chat/completions path (line ~223)
• So the recent [bug] error handling: undefined is not an object #106 anthropic-sse in-stream-error fix doesn't apply here

My guess is the follow-up turn (with tool_result in history) is what the upstream is rejecting — serialization in handlers/shared/format/openai-messages.ts converts Anthropic tool_result blocks to OpenAI role: "tool" messages, and Kimi via zgo may be picky about how those come back (e.g., missing tool_call_id linkage, or content type).

Can you rerun with --debug and share the log? logs/claudish_*.log will have the exact outbound chat/completions payload on the failing turn plus the raw [SSE:openai] response — that'll tell us whether it's our serialization or an upstream Kimi-on-zgo bug.