openclaw - 💡(How to fix) Fix [Bug]: Models do not emit tool calls across multiple providers (openai/groq/ollama) [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Across all model providers tested, the agent never emits tool calls — even though the same models emit clean tool_calls when called directly via their native API. The model describes what it would do as prose (e.g. "I need to authenticate with GitHub CLI...") without invoking any tool. Reproduced on Ollama, Groq, and OpenAI providers (4 different models tested).

Steps to reproduce

1. Fresh setup: openclaw onboard --install-daemon
2. Configure provider auth (any of openai/groq/ollama)
3. openclaw models set <provider/model>
4. Set agents.defaults.sandbox.mode=all (Docker via OrbStack 2.1.1, sandbox image built from scripts/docker/sandbox/Dockerfile)
5. Set agents.defaults.skills=["github","gh-issues"]
6. On host: gh 2.92.0 installed and authenticated (verified with gh auth status)
7. Send a tool-needing prompt:
   openclaw agent --agent main -m "Use gh to fetch the README of <some-repo>"

Expected behavior

Model emits a tool_calls block invoking exec with the gh command. OpenClaw runs gh in the
sandbox, feeds the result back to the model, and the final reply contains the README content.

Actual behavior

Model replies with prose like:

"I need to authenticate with GitHub CLI to access this information. Run gh auth login in your
terminal..."

gh is already authenticated on the host. No tool calls in the gateway log:

  $ openclaw logs | tail -50 | grep -iE "tool_call|tool_use|gh repo|exec.*gh" | wc -l              
  0

openclaw skills check --agent main reports the github skill as Visible to model: yes.
openclaw sandbox explain --agent main shows exec in the default-allow tool policy.

Direct calls to each provider with a tools: [...] array succeed — the same models all emit proper tool_calls. So the issue is in OpenClaw's tool-passing path, not the models.

For example, gpt-5.4-mini called directly returns "tool_calls": [{"function":{"name":"get_weather","arguments":"{\"city\":\"Paris\"}"}}], "finish_reason": "tool_calls". The same prompt + tools schema given to OpenClaw → no tool call in the resulting agent run.

Possibly related to #66926 (Google models writing tool calls as text). Same symptom, different
providers.

OpenClaw version

2026.5.5

Operating system

macOS 15 (Darwin 25.2.0), Apple M3 Ultra

Install method

npm (global)

Model

ollama/qwen3-coder:30b, groq/llama-3.3-70b-versatile, openai/gpt-5.4-mini, openai/gpt-4o (all four reproduce the bug)

Provider / routing chain

Direct provider connections (openai → api.openai.com, groq → api.groq.com, ollama → 127.0.0.1:11434). No proxy or routing layer.

Additional provider/model setup details

• gh 2.92.0 installed via brew, authenticated with a fine-grained PAT

  • OrbStack 2.1.1 as Docker runtime, sandbox image openclaw-sandbox:bookworm-slim rebuilt locally
    from the repo Dockerfile (with gh added)
  • Telegram channel paired with dmPolicy=pairing, single allowed peer
  • Skills allowlist trimmed to ["github","gh-issues"]
  • Reproduced on 2026.5.4 → updated to 2026.5.5 → same behavior

  Diagnostic note: dist/extensions/ollama/ plugin contains no tools / tool_call references;
  appears not to pass tools to Ollama's /api/chat endpoint. For openai/groq, the central
  openai-transport-stream-*.js handles tool_calls but the agent loop never produces tool invocations in practice — suggesting tools either aren't attached to outbound requests, or a system-prompt
  instruction is steering models away from tool calls (similar mechanism to #66926).

  Tried openclaw proxy run -- openclaw gateway start to capture API bodies; that re-bootstrapped the launchd service rather than running gateway under the proxy, so capture didn't catch traffic. The
  launchd-managed gateway makes the actual API calls and we couldn't easily inject HTTPS_PROXY into it without modifying the LaunchAgent plist.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response