#callback-error
Sorted by views, then solution_desc, solution, and root_cause length (desc).
2545 issues
Ollama is installed on a Windows 11 host with `OLLAMA_HOST=0.0.0.0:11434`. It is healthy and reachable from the WSL2 Ubuntu 24.04 host shell. However, from inside a Docker container (NemoClaw sandbox) running inside WSL2, direct connections to the Windows-hosted Ollama instance time out after proxy bypass. This makes it impossible to use Ollama as a local inference backend from containerized workloads on the same machine.
On OpenClaw `2026.4.5`, outbound WhatsApp media sends can return a successful tool result with a real-looking WhatsApp `messageId`, but the recipient only receives the caption/text. The actual attachment never arrives. This affects direct `message` tool sends on WhatsApp.
Hi OpenClaw team, I'm on Windows 10/11, Node v20.20.1 (also tried v22.9.0), npm install -g openclaw@latest succeeds, but dist/gateway.js is missing in the installed package. Steps to reproduce: npm uninstall -g openclaw npm cache clean --force npm install -g openclaw@latest dir "%APPDATA%\npm\node_modules\openclaw\dist\gateway.js" → Path not found openclaw gateway start → Service starts but no node process, port 18789 not listening Browser: http://127.0.0.1:18789/ → ERR_CONNECTION_REFUSED Direct run: node .../dist/gateway.js --port 18789 → Error: Cannot find module '.../dist/gateway.js' Tried: Multiple reinstalls Taobao mirror Deleted ~/.openclaw Task Scheduler task enabled + highest privileges Firewall allows node.exe Disabled antivirus/360 Log snippet: Error: Cannot find module '...\dist\gateway.js' at Module._resolveFilenameName ... Is this a known packaging issue in 2026.3.13? Is there a workaround or fixed version? Thanks for any help!
In `crewai/llm.py`, both `_handle_non_streaming_response()` (line 1220) and `_ahandle_non_streaming_response()` (line 1364) access `params["messages"]` directly when calling `_handle_emit_call_events`, despite having already extracted and validated the messages via `params.get("messages", [])` a few lines earlier. If the `messages` key is missing from `params`, the code correctly raises a helpful `ValueError("Messages are required when using response_model")` at line 1200/1345, but then at line 1220/1364 it would raise a confusing `KeyError` instead.
The webchat control UI model selector incorrectly prefixes all model IDs with `anthropic/`, ignoring the actual provider name. This causes "model not allowed" errors when switching to non-Anthropic models.
After configuring the QMD memory engine for a multi‑agent setup, any operation that runs the **QMD boot/update pipeline via OpenClaw** fails with: - `qmd boot update failed: SafeOpenError: path is not a regular file under root` - `Memory index failed (<agentId>): path is not a regular file under root` At the same time, QMD works correctly when run **directly** with the documented XDG paths, and `openclaw memory status` reports a valid index under the expected per‑agent state directory. For example, `openclaw memory status` for one agent: ```text Memory Search (assistant) Provider: qmd (requested: qmd) Model: qmd Sources: memory, sessions Indexed: 13/19 files · 13 chunks Dirty: no Store: ~/.openclaw/agents/assistant/qmd/xdg-cache/qmd/index.sqlite Workspace: ~/.openclaw/workspace/assistant By source: memory · 13/13 files · 13 chunks sessions · 0/6 files · 0 chunks Vector: ready Batch: disabled (failures 0/0) ``` This `Store:` path lives under the documented per‑agent state directory (`~/.openclaw/agents/<agentId>/qmd/…`) and I don’t think it should trigger `SafeOpenError`. However, when I run `openclaw memory index --force --verbose`, or when the cron job runs the memory indexer, I consistently get: ```text 🦞 OpenClaw 2026.3.28 (f9b1079) Claws out, commit in—let's ship something mildly responsible. Memory Index (main) Provider: qmd (requested: qmd) Model: qmd Sources: memory (MEMORY.md + ~/.openclaw/workspace/memory/*.md), sessions (~/.openclaw/agents/main/sessions/*.jsonl) 19:39:09+00:00 [memory] qmd boot update failed: SafeOpenError: path is not a regular file under root Memory index failed (main): path is not a regular file under root Memory Index (assistant-1) Provider: qmd (requested: qmd) Model: qmd Sources: memory (MEMORY.md + ~/.openclaw/workspace/assistant-1/memory/*.md), sessions (~/.openclaw/agents/assistant-1/sessions/*.jsonl) 19:39:10+00:00 [memory] qmd boot update failed: SafeOpenError: path is not a regular file under root Memory index failed (assistant-1): path is not a regular file under root Memory Index (assistant-2) Provider: qmd (requested: qmd) Model: qmd Sources: memory (MEMORY.md + ~/.openclaw/workspace/assistant-2/memory/*.md), sessions (~/.openclaw/agents/assistant-2/sessions/*.jsonl) 19:39:10+00:00 [memory] qmd boot update failed: SafeOpenError: path is not a regular file under root Memory index failed (assistant-2): path is not a regular file under root ``` In contrast, running QMD directly inside the same container with the documented env vars works and **does not** raise `SafeOpenError`, for example: ```bash STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}" export XDG_CONFIG_HOME="$STATE_DIR/agents/assistant/qmd/xdg-config" export XDG_CACHE_HOME="$STATE_DIR/agents/assistant/qmd/xdg-cache" qmd update && qmd embed && qmd status # → succeeds, uses ~/.openclaw/agents/assistant/qmd/xdg-cache/qmd/index.sqlite ``` So the bug appears to be that **OpenClaw’s memory indexer / cron wrapper is invoking QMD with a different (or mismatched) “root” for the safe‑open check than the one that works when QMD is run directly with the documented XDG paths.**
The `message` tool's `send` action always fails with: ``` Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default. ``` However: - `openclaw channels status --probe` shows: `enabled, configured, linked, running, connected` - Inbound WhatsApp messages are received and routed to sessions correctly - Normal agent replies are delivered to WhatsApp successfully - Only the `message` tool's proactive send (`action=send, channel=whatsapp, target=<phone>`) fails
When `memory.backend: "qmd"` is enabled with `searchMode: "search"` (BM25-only), OpenClaw still calls `qmd status` at boot to probe vector capability. On ARM Linux without Vulkan (e.g. Oracle Cloud aarch64), this causes QMD to attempt a full CMake + llama.cpp compile, fail, hit OpenClaw's 5s containment timeout, and leave all agents with `Vector: unavailable` and 0 chunks indexed.
It seems like the agent is interpreting it's workspace files as my commands (which is totally wrong) and this is visible in the webchat. If I type "/new" to start a new session this gets printed to the chat: "A new session was started via /new or /reset. Run your Session Startup sequence - read the required files before responding to the user. Then greet the user in your configured persona, if one is provided. Be yourself - use your defined voice, mannerisms, and mood. Keep it to 1-3 sentences and ask what they want to do. If the runtime model differs from default_model in the system prompt, mention the default model. Do not mention internal steps, files, tools, or reasoning." And it looks like I've written this message: <img width="1538" height="250" alt="Image" src="https://github.com/user-attachments/assets/6539697e-bdf4-4998-8c44-73067fa4ff0e" />
`openclaw config set` accepts key paths that do not match the config schema, silently writing them to `openclaw.json`. The config is accepted but the setting has no effect because the runtime reads a different path.