Summary
Interactive claw can finish with only ✔ ✨ Done and no visible assistant text when a local OpenAI-compatible llama.cpp/Qwen route returns the assistant reply through a SendUserMessage tool-call-shaped payload instead of normal choices[0].message.content.
Reported reproduction context
From UltraWorkers Discord #claw-code:
- Platform: Windows (
.\target\debug\claw.exe)
- Backend: local llama.cpp OpenAI-compatible server
- Model id:
openai/qwen2.5
- Non-interactive command:
.\target\debug\claw.exe --model "openai/qwen2.5" prompt "say hello"
Observed output includes a tool-call-shaped payload:
{"name":"SendUserMessage","arguments":{"message":"Hello!","status":"normal"}}
and then:
A deterministic raw request later returned normal content:
choices[0].message.content = HELLO_WORLD_123
with no tool_calls, but the user still reports the interactive claw path shows only ✔ ✨ Done after the first command / request.
Expected behavior
If the model/backend returns a user-visible assistant reply either as normal message.content or as the known SendUserMessage payload shape, interactive mode should render the final text instead of only showing completion.
At minimum, if SendUserMessage is not a valid final assistant surface for this mode, claw should report a provider/response-shape warning that explains the mismatch.
Why this is worth tracking
This is a focused local-model compatibility gap, not a generic auth or provider-routing issue. The symptom is especially confusing because the run appears successful (Done) while the visible response is empty.
Suggested investigation
- Compare non-interactive
prompt rendering vs interactive rendering for the same local OpenAI-compatible response.
- Check whether interactive mode treats
SendUserMessage as an internal event/tool result and drops the payload instead of rendering arguments.message.
- Verify fallback behavior when
message.content is present on the second turn but the interactive UI still renders only completion.
- Add a fixture for local OpenAI-compatible responses with:
- final text in
choices[0].message.content
- final text encoded in a
SendUserMessage-shaped tool call
- no final content and no recognized renderable payload
Summary
Interactive
clawcan finish with only✔ ✨ Doneand no visible assistant text when a local OpenAI-compatible llama.cpp/Qwen route returns the assistant reply through aSendUserMessagetool-call-shaped payload instead of normalchoices[0].message.content.Reported reproduction context
From UltraWorkers Discord
#claw-code:.\target\debug\claw.exe)openai/qwen2.5Observed output includes a tool-call-shaped payload:
{"name":"SendUserMessage","arguments":{"message":"Hello!","status":"normal"}}and then:
A deterministic raw request later returned normal content:
with no
tool_calls, but the user still reports the interactiveclawpath shows only✔ ✨ Doneafter the first command / request.Expected behavior
If the model/backend returns a user-visible assistant reply either as normal
message.contentor as the knownSendUserMessagepayload shape, interactive mode should render the final text instead of only showing completion.At minimum, if
SendUserMessageis not a valid final assistant surface for this mode,clawshould report a provider/response-shape warning that explains the mismatch.Why this is worth tracking
This is a focused local-model compatibility gap, not a generic auth or provider-routing issue. The symptom is especially confusing because the run appears successful (
Done) while the visible response is empty.Suggested investigation
promptrendering vs interactive rendering for the same local OpenAI-compatible response.SendUserMessageas an internal event/tool result and drops the payload instead of renderingarguments.message.message.contentis present on the second turn but the interactive UI still renders only completion.choices[0].message.contentSendUserMessage-shaped tool call