#runtime-error
Sorted by views, then solution_desc, solution, and root_cause length (desc).
2685 issues
Every agent response via Claude models (MyClaw provider) triggers an `Unexpected event order, got message_start before receiving "message_stop"` error that is displayed as a visible error message in the Telegram chat. This makes the chat essentially unusable — every reply from the agent is followed by a red error notification. **Affects all Claude models tested** (claude-opus-4.6 and claude-sonnet-4.6). Not yet tested on non-Claude models.
Feishu (飞书) channel cannot send messages when system HTTP proxy is configured. Error: `Cannot destructure property 'tenant_access_token' of '(intermediate value)' as it is undefined.` **Root cause:** The `@larksuiteoapi/node-sdk` uses axios which respects system proxy settings (`http_proxy`/`https_proxy`). When proxy is enabled (e.g., v2rayN), requests to `open.feishu.cn` are routed through the proxy and fail with HTTP 400 error: `"The plain HTTP request was sent to HTTPS port"`.
Run >crewai install error Resolved 149 packages in 107ms error: Distribution `lancedb==0.30.1 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform hint: You're on Windows (`win_amd64`), but `lancedb` (v0.30.1) only has wheels for the following platforms: `manylinux_2_17_aarch64`, `manylinux_2_28_aarch64`, `manylinux_2_28_x86_64`, `manylinux2014_aarch64`, `macosx_11_0_arm64`; consider adding "sys_platform == 'win32' and platform_machine == 'AMD64'" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels An error occurred while running the crew: Command '['uv', 'sync']' returned non-zero exit status 2.
Add configuration to disable external model pricing data fetching during Gateway startup.
Jesus.... you can't do a release with breaking anything eh? After [#35077 #35077](https://github.com/openclaw/openclaw/issues/35077) we're at it again...... <img width="1029" height="651" alt="Image" src="https://github.com/user-attachments/assets/e007d5b7-17fd-435f-b490-56d645be90c2" /> I explicitly asked also in soul.md and agents.md for a feedback after this but it continues to shoot a billion of tool calls without even telling me what the heck is doing. Then at random times, it just sto doing stuff randomly and it acts like it finished. Like, tell me the heck you did. It doesn't complete tasks 50% of the times, it shoots ton of tool calls without giving feedback and more than anything the goddamn UI doesn't update again and again. I have to switch between menu and chat to get a refreshed update with recent tool calls and all. I'm starting to lose hope and switch to something else like hermes agent or picoclaw or whatever else. This is starting to be annoying. Thanks god I'm on free SOTA models. I would have already thrown in the trash hunderd of bucks for child play. EDIT: NOW ASKING TO PRECISELY EDIT THE GITHUB PROJECT I DOWNLOADED THIS STUPID THING EDITED IS OWN OPENCLAW JSON CONFIG AND INCURRED IN COST AND USAGE. JESUS...... ALSO BROKE HIS OWN CONFIG....... NICE, WHAT A JEWEL THIS PROJECT IS.....
When the primary model (OpenAI Codex / ChatGPT Plus OAuth) hits the ChatGPT Plus subscription usage cap, OpenClaw: 1. **Surfaces the error to the UI** even when a fallback model (Anthropic) successfully handles the request 2. **Labels the error as "API rate limit reached"** — misleading when on OAuth (not an API key). The actual failure is a ChatGPT Plus plan usage cap, which is a different condition entirely. 3. **Triggers a WebSocket auth lockout loop** when the user attempts reconnect after a gateway restart, compounding the perceived outage.
On Windows, Feishu channel crashes on startup with ESM module loader error: absolute paths (g:\...) not supported, requires file:// URLs
在 Windows 上执行安装脚本，配置好模型后到下一步时报错：Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]。
When `gateway.auth.token` is migrated from plaintext config to a SecretRef, the Browser Relay server still works, but the Chrome/Brave extension setup flow becomes incomplete. The relay auth path can resolve `gateway.auth.token` from SecretRefs, but the browser extension still expects a literal plaintext token in its own local storage (`chrome.storage.local.gatewayToken`). After hardening gateway auth to use a SecretRef, the extension prompts for a token and cannot discover it through first-party setup.
The WhatsApp health monitor's `stale-socket` restart cycle reliably re-establishes the **personal/inbound listener** but silently fails to reconnect the **Web listener** (used for all proactive outbound sends). This causes all outbound WhatsApp messaging — cron deliveries, `message` tool sends, announce-mode delivery — to fail with: ``` No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default. ``` Meanwhile, inbound DMs continue to work normally (personal listener is fine), masking the failure.
Gateway 访问飞书 API（`open.feishu.cn`）反复超时（10s），但用户本地网络直连飞书服务器正常。
After upgrading to OpenClaw `2026.3.28`, I started seeing repeated local connection attempts from `openclaw-gateway` (`node`) to `127.0.0.1:11434`, even though I was not intentionally using Ollama and did not have an explicit Ollama provider configured in `openclaw.json`. This behavior was visible both in logs and in a local network-monitoring app, which flagged the `node` process for abnormally frequent requests and temporarily blocked/suspended some of its connections. Disabling the bundled `ollama` provider stopped the behavior.
If the agent successfully sends an image/file/text via `message.send(...)`, OpenClaw should suppress the normal main reply / `delivery-mirror` path for that turn. Right now both paths can fire: 1. The agent calls `message.send(...)` 2. The attachment / visible content is delivered successfully 3. The system then also runs a follow-up layer with: - `provider=openclaw` - `model=delivery-mirror` 4. A second extra message appears, often just mirroring text like the filename (for example `cat-fresh.png`)
`web_fetch` fails for all URLs when running behind a transparent proxy (Surge, Clash, etc.) with fake-ip mode enabled. The proxy's DNS hijacking returns addresses in the `198.18.0.0/15` range (RFC 2544 Benchmark Testing), which triggers OpenClaw's SSRF protection.