dependency conflict

🐛 Feishu channel fails with tenant_access_token error when HTTP proxy is configured

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"`.

[BUG] Distribution `lancedb==0.30.1 can't be installed because it doesn't have a source distribution or wheel for the current platform

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.

[Bug]: Ollama Cloud Authentication fails with 401 after update to 2026.3.31

After updating OpenClaw from version 2026.3.24 to 2026.3.31, all requests to Ollama Cloud models fail with HTTP 401 "unauthorized". The same API key works perfectly when tested directly via curl against the Ollama API.

[Feature]: Add option to disable model pricing bootstrap to avoid startup timeout

Add configuration to disable external model pricing data fetching during Gateway startup.

[Bug]: Openclaw is stupid again: 200000 tool calls, no feedback, interruptions

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.....

[Bug]: sessions_spawn(runtime="subagent") can receive ACP-only streamTo from the current tool-call bridge

[Bug]: [AI-Discovered] Feishu channel fails to start on Windows - ESM module loader error

On Windows, Feishu channel crashes on startup with ESM module loader error: absolute paths (g:\...) not supported, requires file:// URLs

[Bug]: Windows 关于 [email protected] 版本在安装时报错：Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]

在 Windows 上执行安装脚本，配置好模型后到下一步时报错：Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]。

[FEATURE] Support using Dispatch in Claude Desktop

Browser Relay extension setup breaks when gateway.auth.token is SecretRef-managed

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.

isGatewayMessageChannel intermittently rejects valid third-party channel plugins (openclaw-weixin, qqbot)

[Bug]:QQBot channel fails to send messages due to missing "to" parameter mapping

The QQBot channel extension has a bug where the CLI --target parameter is not properly mapped to the internal to field required by the QQBot channel implementation, causing message sending to fail. OpenClaw version: 2026.3.11 (29dc654) OS: macOS 15.7.3 (arm64) Node.js: v25.8.0 QQBot extension: @sliverp/qqbot@latest (unpinned version) Additional Context:

WhatsApp Web listener silently dies after health-monitor stale-socket restart

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.

Unexpected local Ollama probing to 127.0.0.1:11434 on 2026.3.28 when Ollama is not explicitly configured

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.

message.send triggers duplicate delivery-mirror replies

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`)

existing-session browser attach hangs while Chrome remote debugging and gateway remain healthy

`existing-session` browser attach hangs on this machine even though Chrome remote debugging stays live and the OpenClaw gateway stays reachable. In the same environment, a local Playwright worker works normally, which isolates the failure to the OpenClaw existing-session path rather than general browser automation.

web_fetch fails with "resolves to private/internal/special-use IP address" in proxy environments using fake-ip mode

`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.

Misleading CDP "Empty reply from server" in WSL2 caused by portproxy self-loop (svchost/iphlpsvc), not Chrome

CDP endpoint returns `curl: (52) Empty reply from server` even when port 9222 appears as LISTENING, because a broken `netsh portproxy` self-loop rule (`127.0.0.1:9222 -> 127.0.0.1:9222`) causes `svchost/iphlpsvc` to own the port instead of Chrome — with no `chrome.exe` process running at all.

Next.js 16.2 build failed: Failed to fetch Google Fonts

False positive cybersecurity-risk warning in benign Codex conversations