Skip to content

Interactive mode shows Done without assistant text for llama.cpp SendUserMessage output #2937

@Yeachan-Heo

Description

@Yeachan-Heo

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:

✔ ✨ Done

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions