database connection

[Bug]: GatewayClientRequestError: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start.

worked in 2026.3.13 (now i fallback to this version) >> openclaw browser --browser-profile openclaw open https://www.baidu.com 🦞 OpenClaw 2026.4.1 (da64a97) — Runs on a Raspberry Pi. Dreams of a rack in Iceland. │ ◇ GatewayClientRequestError: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start.

[Bug]: Vllm + Gemma 4 + claude code: tool calling problems

gateway probe/status reports missing operator.read even when local paired device/token has operator.read

`openclaw gateway probe` / `openclaw status --all` report `missing scope: operator.read` even though the local paired device and local operator token on disk clearly include `operator.read`.

openclaw update does not sync embedded openclaw copy in ~/.openclaw/extensions/node_modules/

unknown model architecture: 'qwen35moe' when loading imported GGUF with mmproj (vision projector)

Imported Qwen3.5-35B-A3B GGUF models fail to load when a vision projector (mmproj) file is attached. The same model loads fine for text-only (without mmproj), and loads fine with mmproj via llama.cpp's --mmproj flag. Ollama version 0.17.7 Steps to reproduce 1. Download a community Qwen 3.5 GGUF (e.g., from llmfan46/Qwen3.5-35B-A3B-heretic-v2-GGUF) and its mmproj file (Qwen3.5-35B-A3B-mmproj-BF16.gguf) 2. Create a Modelfile: FROM Qwen3.5-35B-A3B-heretic-v2-Q5_K_M.gguf FROM Qwen3.5-35B-A3B-mmproj-BF16.gguf TEMPLATE """{{ .Prompt }}""" 3. ollama create qwen3.5:test -f Modelfile → succeeds 4. ollama run qwen3.5:test → fails Also tried ADAPTER instead of second FROM — same result. Error llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'qwen35moe' Expected behavior The model should load with vision support, same as it does with llama.cpp: llama-server -m Qwen3.5-35B-A3B-heretic-v2-Q5_K_M.gguf --mmproj Qwen3.5-35B-A3B-mmproj-BF16.gguf -c 4096 This works perfectly — text and vision both functional. Notes - Without mmproj, the model loads fine for text (families: ['qwen35moe']) - With mmproj, families becomes ['qwen35moe', 'clip'] and loading fails - The official qwen3.5:35b works with vision because it has native qwen35moe.vision.* tensors embedded in the main GGUF — no clip involved - PR #14517 fixed text-only loading of imported qwen35moe GGUFs but the multimodal/clip runner path was not updated for this architecture - GPU: 2x RTX 5060 16GB

[Bug] iMessage inbound messages not received - watch stream not working

mlx runner failed: Error: unsupported architecture: Gemma4ForConditionalGeneration

Bug: openclaw-cli cannot connect to gateway when bind=lan on Docker Desktop macOS (Apple Silicon)

When running the gateway with `gateway.bind=lan` inside Docker Desktop on macOS (Apple Silicon), the `openclaw-cli` container cannot connect to the gateway via WebSocket, making all CLI commands fail. This breaks the documented device pairing flow (`devices list` / `devices approve`).

[Bug]: OpenClaw v2026.03.13 OAuth with openai-codex/gpt-5.3-codex can chat but cannot execute tool actions, and modifying SOUL.md/AGENTS.md has no effect

After authenticating openai-codex/gpt-5.3-codex via OAuth (with proxy to OpenAI from mainland China network), the model can chat normally but refuses to execute any tool operations, even after modifying SOUL.md/AGENTS.md as instructed.

web_search broken — DuckDuckGo returns bot detection since 2026-03-30

[Bug]: OpenClaw v2026.3.13 still sends Ollama an oversized context window (~262144 / 265k), ignoring configured lower limits

OpenClaw `v2026.3.13` still appears to send an extremely large context window to Ollama (around `262144` / `265k`), even when a much lower context size is configured. This looks very similar to the previously reported issue about OpenClaw forcing or propagating an oversized context window to Ollama. Although that issue was marked as fixed, I can still reproduce the behavior on the latest version.

[Bug]: Windows: allowFrom + security: standard does not enable auto-approval for remote commands

Environment | Component | Value | | ---------------- | ------------- | | OS | Windows 10/11 | | OpenClaw Version | 2026.4.1 | | Node.js | v25.7.0 | | Platform | win32 (x64) | ─── Description On Windows, even with security: standard and allowFrom configured, OpenClaw requires explicit approval for every command executed via Telegram. This makes remote management impractical. ─── Configuration { "security": "standard", "channels": { "telegram": { "enabled": true, "dmPolicy": "allowlist", "allowFrom": ["<telegram_user_id>"] } } } ─── Error Message Warning: allowlist auto-execution is unavailable on win32; explicit approval is required. Root Cause The restriction appears to be hardcoded: allowlist auto-execution is unavailable on win32; explicit approval is required ─── Impact • Remote management is impractical on Windows • Every command requires explicit approval • Telegram bot utility is severely limited ─── Suggested Fix

CLI WebSocket handshake timeout - all CLI commands fail to connect gateway

All CLI commands (cron, config, doctor, etc.) fail to connect to the gateway via WebSocket with handshake timeout. The gateway itself runs normally - channel messaging (Feishu) and browser dashboard both work. Only CLI-gateway RPC connections are broken.

CLI `message thread create` does not route to Telegram `createForumTopic`

`openclaw message thread create --channel telegram` fails with: ``` Error: Unsupported Telegram action: thread-create ```

[Bug]: qmd boot update failed: Error: qmd update failed (code 1): file:///C:/software/nvm/v25.8.2/node_modules/@tobilu/qmd/bin/qmd:2 # Resolve symlinks so global installs (npm link / npm install -g) can find the ^

qmd版本2.0.1，openclaw版本20260401.集成qmd后运行报错qmd boot update failed: Error: qmd update failed (code 1): file:///C:/software/nvm/v25.8.2/node_modules/@tobilu/qmd/bin/qmd:2 # Resolve symlinks so global installs (npm link / npm install -g) can find the ^

ollama generate images failed in cuda 13.1

npm install -g shows deprecation warning for [email protected]

[Security] Memory content injected into system prompt without sanitization enables indirect prompt injection

The `LiteAgent` concatenates retrieved memory content directly into the system prompt without sanitization. If memory entries have been poisoned (e.g., via indirect prompt injection through tool outputs), an attacker can inject arbitrary instructions into the system prompt of future agent interactions. **Severity**: MEDIUM **Rule**: AGENT-010 — Unsanitized External Content in Agent Prompt **OWASP Agentic Security Index**: ASI-01 — Prompt Injection **Affected files**: - `lib/crewai/src/crewai/lite_agent.py` (lines 568-581)

[Security] crewai create ships template with eval() on unsanitized LLM input

The `AGENTS.md` template bundled with CrewAI's project scaffolding (`crewai create`) includes a Calculator tool example that uses `eval()` on LLM-provided input, creating a remote code execution vulnerability in every new CrewAI project that follows the template. **Severity**: MEDIUM **Rule**: AGENT-053 — Unsafe Code Execution Pattern in Template **OWASP Agentic Security Index**: ASI-09 — Improper Output Handling **Affected files**: - `lib/crewai/src/crewai/cli/templates/AGENTS.md` (line 773)

Bug: Anthropic OAuth refresh intermittently fails across chats/topics