{"type":"system","subtype":"init","cwd":"./bench/results/mcp-no-toolsearch/list_open_issues/run4/workspace","session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","tools":["Task","TaskOutput","Bash","Glob","Grep","ExitPlanMode","Read","Edit","Write","NotebookEdit","WebFetch","TodoWrite","WebSearch","TaskStop","AskUserQuestion","Skill","EnterPlanMode","EnterWorktree","ExitWorktree","CronCreate","CronDelete","CronList","mcp__chrome-devtools__click","mcp__chrome-devtools__close_page","mcp__chrome-devtools__drag","mcp__chrome-devtools__emulate","mcp__chrome-devtools__evaluate_script","mcp__chrome-devtools__fill","mcp__chrome-devtools__fill_form","mcp__chrome-devtools__get_console_message","mcp__chrome-devtools__get_network_request","mcp__chrome-devtools__handle_dialog","mcp__chrome-devtools__hover","mcp__chrome-devtools__lighthouse_audit","mcp__chrome-devtools__list_console_messages","mcp__chrome-devtools__list_network_requests","mcp__chrome-devtools__list_pages","mcp__chrome-devtools__navigate_page","mcp__chrome-devtools__new_page","mcp__chrome-devtools__performance_analyze_insight","mcp__chrome-devtools__performance_start_trace","mcp__chrome-devtools__performance_stop_trace","mcp__chrome-devtools__press_key","mcp__chrome-devtools__resize_page","mcp__chrome-devtools__select_page","mcp__chrome-devtools__take_memory_snapshot","mcp__chrome-devtools__take_screenshot","mcp__chrome-devtools__take_snapshot","mcp__chrome-devtools__type_text","mcp__chrome-devtools__upload_file","mcp__chrome-devtools__wait_for","mcp__github__add_comment_to_pending_review","mcp__github__add_issue_comment","mcp__github__add_reply_to_pull_request_comment","mcp__github__assign_copilot_to_issue","mcp__github__create_branch","mcp__github__create_or_update_file","mcp__github__create_pull_request","mcp__github__create_pull_request_with_copilot","mcp__github__create_repository","mcp__github__delete_file","mcp__github__fork_repository","mcp__github__get_commit","mcp__github__get_copilot_job_status","mcp__github__get_file_contents","mcp__github__get_label","mcp__github__get_latest_release","mcp__github__get_me","mcp__github__get_release_by_tag","mcp__github__get_tag","mcp__github__get_team_members","mcp__github__get_teams","mcp__github__issue_read","mcp__github__issue_write","mcp__github__list_branches","mcp__github__list_commits","mcp__github__list_issue_types","mcp__github__list_issues","mcp__github__list_pull_requests","mcp__github__list_releases","mcp__github__list_tags","mcp__github__merge_pull_request","mcp__github__pull_request_read","mcp__github__pull_request_review_write","mcp__github__push_files","mcp__github__request_copilot_review","mcp__github__run_secret_scanning","mcp__github__search_code","mcp__github__search_issues","mcp__github__search_pull_requests","mcp__github__search_repositories","mcp__github__search_users","mcp__github__sub_issue_write","mcp__github__update_pull_request","mcp__github__update_pull_request_branch","ListMcpResourcesTool","ReadMcpResourceTool"],"mcp_servers":[{"name":"chrome-devtools","status":"connected"},{"name":"github","status":"connected"},{"name":"claude.ai Google Calendar","status":"needs-auth"},{"name":"claude.ai Gmail","status":"needs-auth"}],"model":"claude-sonnet-4-6","permissionMode":"bypassPermissions","slash_commands":["update-config","debug","simplify","batch","loop","claude-api","test-driven-development","app-installer","release-notify-issues","cli-demo-recorder","readme-generator","compact","context","cost","heapdump","init","pr-comments","release-notes","review","security-review","extra-usage","insights","mcp__github__AssignCodingAgent","mcp__github__issue_to_fix_workflow"],"apiKeySource":"none","claude_code_version":"2.1.77","output_style":"default","agents":["general-purpose","statusline-setup","Explore","Plan","claude-code-guide"],"skills":["update-config","debug","simplify","batch","loop","claude-api","test-driven-development","app-installer","release-notify-issues","cli-demo-recorder","readme-generator"],"plugins":[],"uuid":"ec9ac5e5-493e-4f4b-aacc-67910188d563","fast_mode_state":"off"}
{"type":"assistant","message":{"model":"claude-sonnet-4-6","id":"msg_01XT3RexhASejmEUoW1kJzk2","type":"message","role":"assistant","content":[{"type":"thinking","thinking":"Let me list the open issues in the openclaw/openclaw repository.","signature":"EugBCkYICxgCKkDXIwVqbJWrMgOf/8rXcWDtFR0HuT8z9NTYFZxAjuK9lOudgpc6Ya2A6leFWP9rI15b7q92ewNusL1fqfHsMOtsEgwUwpRc2NyRqvVHzWUaDGhg+BrKva9kBvVdmSIwt+jX2scUX+bg/j2ShdsBJHm8rx2wzP9QVVN3DhoGLw6XMw7CHPxnypVZD6MCSEzRKlDDV8WZvkmergg2/mvof6vHsV7zJn0Co6IF7wFNmuHc38R2Kn4XC26LQ+3aJZOggc/E2V4qilnLJMhl7YuR69Z2193G/mxU4mO/yD27BWXlIxgB"}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":3,"cache_creation_input_tokens":0,"cache_read_input_tokens":40990,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":0},"output_tokens":1,"service_tier":"standard","inference_geo":"not_available"},"context_management":null},"parent_tool_use_id":null,"session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","uuid":"d9b0244c-8990-45e4-84b5-908e72792555"}
{"type":"assistant","message":{"model":"claude-sonnet-4-6","id":"msg_01XT3RexhASejmEUoW1kJzk2","type":"message","role":"assistant","content":[{"type":"tool_use","id":"toolu_0132Ha3H2FhWZsAYiwHFWpsh","name":"mcp__github__list_issues","input":{"owner":"openclaw","repo":"openclaw","state":"OPEN","orderBy":"CREATED_AT","direction":"DESC","perPage":10},"caller":{"type":"direct"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":3,"cache_creation_input_tokens":0,"cache_read_input_tokens":40990,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":0},"output_tokens":1,"service_tier":"standard","inference_geo":"not_available"},"context_management":null},"parent_tool_use_id":null,"session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","uuid":"151f9808-32d4-4350-8319-5fa31a0cc9d8"}
{"type":"rate_limit_event","rate_limit_info":{"status":"allowed","resetsAt":1774126800,"rateLimitType":"five_hour","overageStatus":"rejected","overageDisabledReason":"org_level_disabled","isUsingOverage":false},"uuid":"d25d961a-58bd-45c0-bb0c-34c4a4452c69","session_id":"cf92efe0-6762-49b2-8029-04c689e1302f"}
{"type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_0132Ha3H2FhWZsAYiwHFWpsh","type":"tool_result","content":[{"type":"text","text":"{\"issues\":[{\"number\":51800,\"title\":\"Web UI: onAttachmentsChange callback is undefined, paste image not delivered to Gateway\",\"body\":\"## Bug Description\\n\\nPasting an image in the Web UI control panel does not deliver the image to the Gateway/agent. The image is detected by the paste handler (console logs show the base64 dataUrl), but the `onAttachmentsChange` callback is undefined, causing the handler to return early without updating `chatAttachments`.\\n\\n## Steps to Reproduce\\n\\n1. Open the OpenClaw Web UI control panel\\n2. In the browser Console, run:\\n   ```js\\n   document.querySelector(\\u0026#39;openclaw-app\\u0026#39;).onAttachmentsChange\\n   ```\\n   Result: `undefined`\\n3. Paste an image (Ctrl+V) into the chat input\\n4. Check `chatAttachments`:\\n   ```js\\n   document.querySelector(\\u0026#39;openclaw-app\\u0026#39;).chatAttachments\\n   ```\\n   Result: `[]` (empty)\\n\\n## Root Cause\\n\\nIn the minified paste handler `f$`, the logic is:\\n```js\\nif(!n||!t.onAttachmentsChange)return;\\n```\\n\\nSince `t.onAttachmentsChange` is undefined, the function returns immediately after detecting clipboard items. The base64 dataUrl is logged (custom debug code in the handler fires), but the attachment is never added to the chat message sent to Gateway.\\n\\nThe `onAttachmentsChange` prop is supposed to be passed from `ChatCompose` via:\\n```js\\nonAttachmentsChange: b =\\u0026gt; e.chatAttachments = b\\n```\\nBut it appears this prop binding is broken, the callback is not being attached to the component\\u0026#39;s public property.\\n\\n## Expected Behavior\\n\\nPasted images should be added to `chatAttachments` and delivered to the Gateway as media attachments, then processed by the agent\\u0026#39;s `image` tool.\\n\\n## Environment\\n\\n- OS: Windows 11\\n- OpenClaw: installed via npm global\\n- Browser: Chrome\\n- Channel: Web UI (openclaw-control-ui)\\n- Agent: main (glm-5)\\n\",\"state\":\"OPEN\",\"user\":{\"login\":\"lulu-claude\"},\"comments\":1,\"created_at\":\"2026-03-21T18:10:16Z\",\"updated_at\":\"2026-03-21T18:15:34Z\"},{\"number\":51798,\"title\":\"Bug: image tool returns \\u0026#39;Model does not support images\\u0026#39; for ollama/qwen3-vl:2b despite VL model working via direct API\",\"body\":\"**OpenClaw Version:** 2026.3.13 (61d171a)\\n\\n**Config:** agents.defaults.imageModel.primary = \\\\\\u0026#34;ollama/qwen3-vl:2b\\\\\\u0026#34;\\n\\n**Steps to reproduce:**\\n1. Set agents.defaults.imageModel to ollama/qwen3-vl:2b\\n2. Call the image tool with any image, e.g.: image(prompt=\\\\\\u0026#34;Describe this image\\\\\\u0026#34;, image=\\\\\\u0026#34;/path/to/photo.jpg\\\\\\u0026#34;)\\n\\n**Expected:** Model analyzes the image and returns a description.\\n\\n**Actual:** Returns error:\\n```\\nModel does not support images: ollama/qwen3-vl:2b\\n```\\n\\n**Root cause (suspected):** The image tool appears to use a capability check that fails to detect qwen3-vl:2b as a vision model, even though:\\n- ollama list correctly shows qwen3-vl:2b is installed\\n- Direct curl to http://localhost:11434/api/generate with the same model and base64-encoded image works perfectly and returns accurate image descriptions\\n\\n**Reproduction environment:**\\n- Ollama running locally with qwen3-vl:2b installed\\n- Model confirmed working via direct API with image input\\n- OpenClaw image tool fails with \\\\\\u0026#34;does not support images\\\\\\u0026#34; error\\n\\n**Tags:** bug, vision, ollama, image-tool\",\"state\":\"OPEN\",\"user\":{\"login\":\"wangsen992\"},\"created_at\":\"2026-03-21T18:05:32Z\",\"updated_at\":\"2026-03-21T18:05:32Z\"},{\"number\":51797,\"title\":\"Bug: Exec命令在Windows下参数空格丢失导致命令失败\",\"body\":\"## 🐛 Bug描述\\n\\nOpenClaw在执行Windows命令时，会出现命令参数空格丢失的问题，导致命令无法正确解析和执行。\\n\\n### 复现步骤\\n\\n1. 使用OpenClaw的exec工具执行Windows命令\\n2. 命令包含Windows参数格式（如 \\n/PID\\n, \\n/IM\\n, \\n/F\\n）\\n3. 观察到参数与值之间缺少空格\\n\\n### 示例\\n\\n**期望命令:**一大段文本）\",\"state\":\"OPEN\",\"user\":{\"login\":\"zy00010\"},\"comments\":1,\"created_at\":\"2026-03-21T18:05:30Z\",\"updated_at\":\"2026-03-21T18:16:13Z\"},{\"number\":51796,\"title\":\"Inkonsistentes Verhalten bei exec Genehmigungs-Popups in OpenClaw Control UI\",\"body\":\"Hallo OpenClaw-Team,\\n\\nich möchte ein inkonsistentes Verhalten bei den `exec`-Genehmigungs-Popups in der OpenClaw Control UI melden, das wir bei umfangreichen Tests reproduzieren konnten.\\n\\n**Problembeschreibung:**\\nObwohl `tools.exec.ask` in der `openclaw.json` auf `\\u0026#34;always\\u0026#34;` gesetzt ist, erscheinen Genehmigungs-Popups (Approval Requests) in der Web-Oberfläche (openclaw-control-ui) nicht konsequent für *alle* `exec`-Befehle. Insbesondere konnten wir beobachten, dass nach einer **erfolgreichen manuellen Genehmigung eines `exec`-Befehls die direkt folgenden `exec`-Befehle (auch mit `ask=\\u0026#34;always\\u0026#34;`) ohne erneute Popup-Anzeige ausgeführt werden.**\\n\\n**Reproduktionsschritte:**\\n\\n1.  **Voraussetzung:** `tools.exec.ask` ist in `/root/.openclaw/openclaw.json` auf `\\u0026#34;always\\u0026#34;` gesetzt. `tools.elevated.enabled` ist ebenfalls auf `true` gesetzt und `allowFrom` für `webchat` (`openclaw-control-ui`) ist konfiguriert.\\n2.  **Schritt 1:** Führen Sie einen `exec`-Befehl aus, der ein Popup anfordert (z.B. `openclaw.exec(ask=\\u0026#34;always\\u0026#34;, command=\\u0026#34;cat /etc/os-release\\u0026#34;)`).\\n3.  **Schritt 2:** Der Benutzer genehmigt diesen Befehl über das angezeigte Popup.\\n4.  **Schritt 3:** Führen Sie **unmittelbar danach** einen *anderen* `exec`-Befehl aus (z.B. `openclaw.exec(ask=\\u0026#34;always\\u0026#34;, command=\\u0026#34;uptime\\u0026#34;)`).\\n\\n**Erwartetes Ergebnis:**\\nFür den Befehl in Schritt 3 sollte ebenfalls ein Freigabe-Popup erscheinen.\\n\\n**Tatsächliches Ergebnis:**\\nFür den Befehl in Schritt 3 erscheint **kein** Freigabe-Popup; der Befehl wird direkt ausgeführt.\\n\\n**Zusätzliche Beobachtungen:**\\n\\n*   **Zeitliche Verzögerung:** Wir haben Tests mit `sleep` zwischen dem ersten und zweiten Befehl durchgeführt (1, 5, 10, 30 Sekunden). Das Verhalten blieb konsistent: Auch nach 30 Sekunden Pause erschien kein zweites Popup. Dies deutet darauf hin, dass es kein einfaches Timeout-Problem ist.\\n*   **Reset-Verhalten:** Ein `docker restart openclaw` auf dem Host-System setzt das Verhalten temporär zurück. Nach einem Neustart erscheint das erste Popup (z.B. für den Reset der `exec-approvals.json`) wieder korrekt. Danach beginnt das inkonsistente Verhalten erneut.\\n*   **`exec-approvals.json`:** Die Datei `/root/.openclaw/exec-approvals.json` war während der Tests leer (`{}`), was ausschließt, dass eine pauschale `\\u0026#34;allow-always\\u0026#34;` Regel das Problem verursacht.\\n\\n**Umgebung:**\\n\\n*   **OpenClaw Version:** 2026.3.13 (61d171a)\\n*   **Betriebssystem des Hosts (Nexus):** AlmaLinux 9.4 (Seaborgium) (korrigiert nach deiner Rückmeldung)\\n*   **OpenClaw läuft in Docker (Debian-basiert).**\\n*   **Frontend:** OpenClaw Control UI (Webchat)\\n\\nDieses Verhalten untergräbt die beabsichtigte Sicherheitsfunktion von `ask=\\u0026#34;always\\u0026#34;`, da Befehle unbemerkt ausgeführt werden könnten.\\n\\nVielen Dank für Ihre Unterstützung bei der Untersuchung und Behebung dieses Problems.\\n\\nMit freundlichen Grüßen,\\n\\n[Dein Name / Tommy]\",\"state\":\"OPEN\",\"user\":{\"login\":\"Peilsender\"},\"comments\":1,\"created_at\":\"2026-03-21T18:04:11Z\",\"updated_at\":\"2026-03-21T18:15:34Z\"},{\"number\":51794,\"title\":\"secretref-env: not working for Discord token in channels.discord.token\",\"body\":\"## Description\\n\\nThe `secretref-env:` format is not working correctly for the Discord token in `channels.discord.token` configuration.\\n\\n## Steps to Reproduce\\n\\n1. Set Discord token in systemd service environment:\\n   ```\\n   Environment=OPENCLAW_DISCORD_TOKEN=MTQ2OTgyNjA0MjU0NDkxODYyMA.GvPdPl...\\n   ```\\n\\n2. Configure Discord channel with secretref-env:\\n   ```json\\n   \\u0026#34;channels\\u0026#34;: {\\n     \\u0026#34;discord\\u0026#34;: {\\n       \\u0026#34;enabled\\u0026#34;: true,\\n       \\u0026#34;token\\u0026#34;: \\u0026#34;secretref-env:OPENCLAW_DISCORD_TOKEN\\u0026#34;\\n     }\\n   }\\n   ```\\n\\n3. Start the gateway\\n\\n## Expected Behavior\\n\\nGateway should read the `OPENCLAW_DISCORD_TOKEN` environment variable and use its value to authenticate with Discord API.\\n\\n## Actual Behavior\\n\\nGateway returns 401 Unauthorized errors:\\n```\\n[discord] channel resolve failed; using config entries. Discord API /users/@me/guilds failed (401): 401: Unauthorized\\n```\\n\\n## Verification\\n\\n- Token is present in gateway process environment (verified via `/proc//environ`)\\n- Token works when tested directly with Discord API via curl\\n- Same token works when placed directly in config (not using secretref-env)\\n\\n## Workaround\\n\\nPlace token directly in config file:\\n```json\\n\\u0026#34;token\\u0026#34;: \\u0026#34;MTQ2OTgyNjA0MjU0NDkxODYyMA.GvPdPl...\\u0026#34;\\n```\\n\\n## Environment\\n\\n- OpenClaw version: 2026.3.13\\n- OS: Ubuntu 24.04.4 LTS\\n- Node: v22.22.0\\n\\n## Security Note\\n\\nThe workaround of putting tokens directly in config is less secure than using environment variables. This bug forces users to choose between a working Discord integration and better security practices.\",\"state\":\"OPEN\",\"user\":{\"login\":\"halointellicore\"},\"comments\":1,\"created_at\":\"2026-03-21T18:01:51Z\",\"updated_at\":\"2026-03-21T18:02:34Z\"},{\"number\":51793,\"title\":\"[Feature]: Multi-chat / tabbed sessions in webchat UI\",\"body\":\"## Feature Request\\n\\n**Problem:**\\nThe webchat UI currently supports only a single session. There\\u0026#39;s no way to have multiple parallel conversations like you can in ChatGPT, Codex, or Claude — where you have a sidebar of chats and can switch between them.\\n\\n**Desired behavior:**\\n- Tabbed or sidebar-based multi-session support in the webchat UI\\n- Ability to create new chats, switch between them, and see chat history\\n- Each chat should be an independent session with its own context\\n- Similar UX to Codex app\\u0026#39;s multi-conversation sidebar\\n\\n**Current workarounds:**\\n- Using different channels (webchat + Telegram) as separate sessions\\n- Spawning sub-agents for background tasks\\n- Opening multiple browser tabs (shares the same session)\\n\\n**Why it matters:**\\nPower users want to run multiple workstreams in parallel — e.g., one chat for coding, one for email/calendar, one for research — without context bleeding between them.\\n\\n---\\n_Filed via OpenClaw agent on behalf of user._\",\"state\":\"OPEN\",\"user\":{\"login\":\"aquaright1\"},\"comments\":2,\"created_at\":\"2026-03-21T17:54:21Z\",\"updated_at\":\"2026-03-21T18:00:40Z\"},{\"number\":51789,\"title\":\"Feature: `workspace.extraFiles` config for injecting additional bootstrap files\",\"body\":\"## Problem\\n\\nOpenClaw auto-injects a fixed set of top-level workspace files into the system prompt (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, etc.). There\\u0026#39;s no config option to inject additional files from subdirectories.\\n\\nThe current workaround is writing a custom `agent:bootstrap` hook that adds files to `context.bootstrapFiles`. This works but has a subtle bug: the bootstrap cache returns the **same array reference** on each call, so if a hook appends to it, the additions persist in the cache and accumulate on subsequent calls (compaction cycles, `/context` commands, etc.). We measured ~8x duplication, wasting 40-50K tokens per session.\\n\\nThe bundled `bootstrap-extra-files` hook avoids this by creating a fresh array, but there\\u0026#39;s no documentation warning custom hook authors about this behavior.\\n\\n## Proposed Solution\\n\\nAdd a config option like `agents.defaults.workspace.extraFiles` that accepts file paths or globs relative to the workspace:\\n\\n```json\\n{\\n  \\u0026#34;agents\\u0026#34;: {\\n    \\u0026#34;defaults\\u0026#34;: {\\n      \\u0026#34;workspace\\u0026#34;: {\\n        \\u0026#34;extraFiles\\u0026#34;: [\\n          \\u0026#34;prompts/CALENDARS.md\\u0026#34;,\\n          \\u0026#34;prompts/TECHNICAL.md\\u0026#34;,\\n          \\u0026#34;prompts/TODO.md\\u0026#34;\\n        ]\\n      }\\n    }\\n  }\\n}\\n```\\n\\nThese files would be resolved and injected alongside the built-in bootstrap files, using the same per-file and total character limits (`bootstrapMaxChars`, `bootstrapTotalMaxChars`).\\n\\n## Why This Helps\\n\\n1. **Eliminates the most common custom hook use case** — most bootstrap hooks just inject extra workspace files. A config option makes this declarative and safe.\\n2. **Avoids the cache mutation issue entirely** — users don\\u0026#39;t need to write hooks that interact with the cached array.\\n3. **Consistent with existing config patterns** — fits naturally alongside `bootstrapMaxChars` and `bootstrapTotalMaxChars`.\\n\\n## Alternatives Considered\\n\\n- **Return a copy from cache** — `resolveBootstrapFilesForRun` could return a copy instead of the original reference. Fixes the duplication but still requires boilerplate hooks for a simple \\u0026#34;include these files\\u0026#34; use case.\\n- **Documentation** — warn hook authors not to modify `context.bootstrapFiles` in place. Helps but doesn\\u0026#39;t eliminate the need for custom hooks.\\n\\n## Environment\\n\\n- OpenClaw 2026.3.2+\\n- Discovered while debugging 8x file duplication in a custom `agent:bootstrap` hook\",\"state\":\"OPEN\",\"user\":{\"login\":\"Maninae\"},\"created_at\":\"2026-03-21T17:42:17Z\",\"updated_at\":\"2026-03-21T17:42:17Z\"},{\"number\":51788,\"title\":\"Bug: Control UI prefixes xAI model IDs with \\u0026#39;anthropic/\\u0026#39; causing GatewayRequestError\",\"body\":\"## Summary\\n\\nWhen switching models via the Control UI (dropdown or `/model` command), xAI model IDs are sent to the gateway with an incorrect `anthropic/` prefix instead of `xai/`. This causes a `GatewayRequestError: model not allowed` for every xAI model.\\n\\n## Environment\\n\\n- **Version:** OpenClaw 2026.3.13 (61d171a)\\n- **OS:** macOS 26.3.1 (arm64)\\n- **Node:** 25.6.1\\n- **Channel:** webchat (Control UI)\\n\\n## Steps to Reproduce\\n\\n1. Configure xAI models in `agents.defaults.models` (e.g. `xai/grok-4.20-0309-reasoning`)\\n2. Add `xai:default` auth profile\\n3. Open Control UI and switch model via dropdown or `/model grok-4.2-r`\\n4. Observe error\\n\\n## Actual Behavior\\n\\nGateway receives model ID with wrong provider prefix:\\n\\n```\\nGatewayRequestError: model not allowed: anthropic/grok-4.20-0309-reasoning\\n```\\n\\nGateway logs (repeated across multiple attempts and UI reconnects):\\n\\n```\\n[ws] ⇄ res ✗ sessions.patch 6ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 7ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 12ms errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 8ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4-fast-non-reasoning\\n```\\n\\nThe pattern is consistent — **any** xAI model selected in the UI gets sent as `anthropic/` instead of `xai/`.\\n\\n## Expected Behavior\\n\\n`xai/grok-4.20-0309-reasoning` should be sent as-is, matching the allowlist entry.\\n\\n## Config (relevant excerpt)\\n\\n```json\\n\\u0026#34;agents\\u0026#34;: {\\n  \\u0026#34;defaults\\u0026#34;: {\\n    \\u0026#34;models\\u0026#34;: {\\n      \\u0026#34;xai/grok-4.20-0309-reasoning\\u0026#34;: { \\u0026#34;alias\\u0026#34;: \\u0026#34;grok-4.2-r\\u0026#34; },\\n      \\u0026#34;xai/grok-4.20-0309-non-reasoning\\u0026#34;: { \\u0026#34;alias\\u0026#34;: \\u0026#34;grok-4.2\\u0026#34; }\\n    }\\n  }\\n},\\n\\u0026#34;auth\\u0026#34;: {\\n  \\u0026#34;profiles\\u0026#34;: {\\n    \\u0026#34;anthropic:default\\u0026#34;: { \\u0026#34;provider\\u0026#34;: \\u0026#34;anthropic\\u0026#34;, \\u0026#34;mode\\u0026#34;: \\u0026#34;api_key\\u0026#34; },\\n    \\u0026#34;xai:default\\u0026#34;: { \\u0026#34;provider\\u0026#34;: \\u0026#34;xai\\u0026#34;, \\u0026#34;mode\\u0026#34;: \\u0026#34;api_key\\u0026#34; }\\n  }\\n}\\n```\\n\\n## Workaround\\n\\nNone found via UI. Clearing browser storage and hard refresh do not help. The bug appears to be in how the Control UI constructs the model ID before sending `sessions.patch` over WebSocket.\",\"state\":\"OPEN\",\"user\":{\"login\":\"neuvalbe\"},\"comments\":1,\"created_at\":\"2026-03-21T17:42:14Z\",\"updated_at\":\"2026-03-21T18:03:09Z\"},{\"number\":51787,\"title\":\"[Question] Is there interest in a managed hosting option for OpenClaw?\",\"body\":\"Hi, I\\u0026#39;ve been working on a managed hosting service for OpenClaw ([openclawup.com](https://openclawup.com)) that handles all the server setup, AI API keys, and deployment automatically.\\n\\nBefore I invest more time, I wanted to check with this community:\\n- Would a managed hosting option be useful for you or your team?\\n- What\\u0026#39;s the biggest pain point when self-hosting OpenClaw?\\n\\n**What it does (so far):**\\n- One-click deploy to Telegram or Discord (~60 seconds)\\n- 9 AI models included (Claude, GPT, Gemini, DeepSeek, etc.) — no API keys needed\\n- Free 3-day trial, no credit card required\\n- You can try the AI right on the homepage before signing up\\n\\nI\\u0026#39;m not trying to spam — genuinely looking for feedback from people who actually use OpenClaw. If this isn\\u0026#39;t the right place for this kind of post, happy to remove it.\\n\\nThanks!\",\"state\":\"OPEN\",\"user\":{\"login\":\"wolfqing\"},\"comments\":1,\"created_at\":\"2026-03-21T17:40:35Z\",\"updated_at\":\"2026-03-21T18:15:56Z\"},{\"number\":51785,\"title\":\"WhatsApp outbound send to new contact fails despite linked session\",\"body\":\"## Bug report — WhatsApp outbound send to new contact fails despite linked session\\n\\n**Context**\\n- OpenClaw version: `2026.3.13`\\n- OS: Windows 11\\n- Gateway local in loopback mode\\n- WhatsApp account: `default`\\n- inbound WhatsApp works with my own number\\n- goal: send an outbound WhatsApp message to a new contact (`+33695994586`)\\n\\n**Symptoms**\\n- inbound WhatsApp works\\n- `openclaw status --deep` often shows:\\n  - `WhatsApp | LINKED`\\n- logs also show:\\n  - `Linked after restart; web session ready`\\n  - `Listening for personal WhatsApp inbound messages`\\n\\nBut outbound sends via the native `message` tool fail with inconsistent errors.\\n\\n**Errors observed**\\n1. With E.164 target:\\n- `Error: Delivering to WhatsApp requires target `\\n\\nTested with:\\n- `+33695994586`\\n- `33695994586`\\n- `+33695994586@s.whatsapp.net`\\n- `33695994586@c.us`\\n\\n2. With `targets` variant:\\n- `Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.`\\n\\n**Important**\\n- the account appears **linked**\\n- inbound works\\n- gateway is reachable\\n- outbound/listener state appears inconsistent with linked state\\n\\n**What we already did**\\n- repaired semantic memory (switched to Gemini embeddings)\\n- installed Git\\n- installed Python + tzdata\\n- set up Gmail digest scripts\\n- explicitly exposed the `message` tool via config:\\n  - `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`\\n- set session visibility:\\n  - `tools.sessions.visibility = \\u0026#34;agent\\u0026#34;`\\n- restarted the gateway multiple times\\n- attempted WhatsApp relink:\\n  - `openclaw channels login --channel whatsapp --account default`\\n- relink output:\\n  - `✅ Linked! Credentials saved for future sends.`\\n\\n**Findings**\\n- before config changes, `message` tool was not exposed in this session\\n- after adding `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`, the native `message` tool became available\\n- `sessions_send` can reach another OpenClaw session, but does not guarantee a real external WhatsApp delivery\\n- the issue now seems isolated to:\\n  - WhatsApp target validation in `message.send`\\n  - and/or outbound listener state detection after relink\\n\\n**Relevant config**\\n- `tools.profile = \\u0026#34;coding\\u0026#34;`\\n- `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`\\n- `tools.sessions.visibility = \\u0026#34;agent\\u0026#34;`\\n- `channels.whatsapp.enabled = true`\\n- `channels.whatsapp.dmPolicy = \\u0026#34;allowlist\\u0026#34;`\\n- `channels.whatsapp.allowFrom = [\\u0026#34;+33619994507\\u0026#34;]`\\n\\n**Hypothesis**\\nThere may be a bug in one or more of:\\n- WhatsApp E.164 target validation in `message.send`\\n- detection of active WhatsApp Web listener after relink\\n- divergence between inbound linked state and outbound send readiness\\n\",\"state\":\"OPEN\",\"user\":{\"login\":\"kraffes\"},\"comments\":1,\"created_at\":\"2026-03-21T17:30:50Z\",\"updated_at\":\"2026-03-21T17:36:05Z\"}],\"totalCount\":8763,\"pageInfo\":{\"hasNextPage\":true,\"hasPreviousPage\":false,\"startCursor\":\"Y3Vyc29yOnYyOpK5MjAyNi0wMy0yMVQxMToxMDoxNi0wNzowMM71KytV\",\"endCursor\":\"Y3Vyc29yOnYyOpK5MjAyNi0wMy0yMVQxMDozMDo1MC0wNzowMM71KVel\"}}"}]}]},"parent_tool_use_id":null,"session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","uuid":"ac726001-221b-4939-bc00-0c341588d9c4","timestamp":"2026-03-21T18:25:23.007Z","tool_use_result":[{"type":"text","text":"{\"issues\":[{\"number\":51800,\"title\":\"Web UI: onAttachmentsChange callback is undefined, paste image not delivered to Gateway\",\"body\":\"## Bug Description\\n\\nPasting an image in the Web UI control panel does not deliver the image to the Gateway/agent. The image is detected by the paste handler (console logs show the base64 dataUrl), but the `onAttachmentsChange` callback is undefined, causing the handler to return early without updating `chatAttachments`.\\n\\n## Steps to Reproduce\\n\\n1. Open the OpenClaw Web UI control panel\\n2. In the browser Console, run:\\n   ```js\\n   document.querySelector(\\u0026#39;openclaw-app\\u0026#39;).onAttachmentsChange\\n   ```\\n   Result: `undefined`\\n3. Paste an image (Ctrl+V) into the chat input\\n4. Check `chatAttachments`:\\n   ```js\\n   document.querySelector(\\u0026#39;openclaw-app\\u0026#39;).chatAttachments\\n   ```\\n   Result: `[]` (empty)\\n\\n## Root Cause\\n\\nIn the minified paste handler `f$`, the logic is:\\n```js\\nif(!n||!t.onAttachmentsChange)return;\\n```\\n\\nSince `t.onAttachmentsChange` is undefined, the function returns immediately after detecting clipboard items. The base64 dataUrl is logged (custom debug code in the handler fires), but the attachment is never added to the chat message sent to Gateway.\\n\\nThe `onAttachmentsChange` prop is supposed to be passed from `ChatCompose` via:\\n```js\\nonAttachmentsChange: b =\\u0026gt; e.chatAttachments = b\\n```\\nBut it appears this prop binding is broken, the callback is not being attached to the component\\u0026#39;s public property.\\n\\n## Expected Behavior\\n\\nPasted images should be added to `chatAttachments` and delivered to the Gateway as media attachments, then processed by the agent\\u0026#39;s `image` tool.\\n\\n## Environment\\n\\n- OS: Windows 11\\n- OpenClaw: installed via npm global\\n- Browser: Chrome\\n- Channel: Web UI (openclaw-control-ui)\\n- Agent: main (glm-5)\\n\",\"state\":\"OPEN\",\"user\":{\"login\":\"lulu-claude\"},\"comments\":1,\"created_at\":\"2026-03-21T18:10:16Z\",\"updated_at\":\"2026-03-21T18:15:34Z\"},{\"number\":51798,\"title\":\"Bug: image tool returns \\u0026#39;Model does not support images\\u0026#39; for ollama/qwen3-vl:2b despite VL model working via direct API\",\"body\":\"**OpenClaw Version:** 2026.3.13 (61d171a)\\n\\n**Config:** agents.defaults.imageModel.primary = \\\\\\u0026#34;ollama/qwen3-vl:2b\\\\\\u0026#34;\\n\\n**Steps to reproduce:**\\n1. Set agents.defaults.imageModel to ollama/qwen3-vl:2b\\n2. Call the image tool with any image, e.g.: image(prompt=\\\\\\u0026#34;Describe this image\\\\\\u0026#34;, image=\\\\\\u0026#34;/path/to/photo.jpg\\\\\\u0026#34;)\\n\\n**Expected:** Model analyzes the image and returns a description.\\n\\n**Actual:** Returns error:\\n```\\nModel does not support images: ollama/qwen3-vl:2b\\n```\\n\\n**Root cause (suspected):** The image tool appears to use a capability check that fails to detect qwen3-vl:2b as a vision model, even though:\\n- ollama list correctly shows qwen3-vl:2b is installed\\n- Direct curl to http://localhost:11434/api/generate with the same model and base64-encoded image works perfectly and returns accurate image descriptions\\n\\n**Reproduction environment:**\\n- Ollama running locally with qwen3-vl:2b installed\\n- Model confirmed working via direct API with image input\\n- OpenClaw image tool fails with \\\\\\u0026#34;does not support images\\\\\\u0026#34; error\\n\\n**Tags:** bug, vision, ollama, image-tool\",\"state\":\"OPEN\",\"user\":{\"login\":\"wangsen992\"},\"created_at\":\"2026-03-21T18:05:32Z\",\"updated_at\":\"2026-03-21T18:05:32Z\"},{\"number\":51797,\"title\":\"Bug: Exec命令在Windows下参数空格丢失导致命令失败\",\"body\":\"## 🐛 Bug描述\\n\\nOpenClaw在执行Windows命令时，会出现命令参数空格丢失的问题，导致命令无法正确解析和执行。\\n\\n### 复现步骤\\n\\n1. 使用OpenClaw的exec工具执行Windows命令\\n2. 命令包含Windows参数格式（如 \\n/PID\\n, \\n/IM\\n, \\n/F\\n）\\n3. 观察到参数与值之间缺少空格\\n\\n### 示例\\n\\n**期望命令:**一大段文本）\",\"state\":\"OPEN\",\"user\":{\"login\":\"zy00010\"},\"comments\":1,\"created_at\":\"2026-03-21T18:05:30Z\",\"updated_at\":\"2026-03-21T18:16:13Z\"},{\"number\":51796,\"title\":\"Inkonsistentes Verhalten bei exec Genehmigungs-Popups in OpenClaw Control UI\",\"body\":\"Hallo OpenClaw-Team,\\n\\nich möchte ein inkonsistentes Verhalten bei den `exec`-Genehmigungs-Popups in der OpenClaw Control UI melden, das wir bei umfangreichen Tests reproduzieren konnten.\\n\\n**Problembeschreibung:**\\nObwohl `tools.exec.ask` in der `openclaw.json` auf `\\u0026#34;always\\u0026#34;` gesetzt ist, erscheinen Genehmigungs-Popups (Approval Requests) in der Web-Oberfläche (openclaw-control-ui) nicht konsequent für *alle* `exec`-Befehle. Insbesondere konnten wir beobachten, dass nach einer **erfolgreichen manuellen Genehmigung eines `exec`-Befehls die direkt folgenden `exec`-Befehle (auch mit `ask=\\u0026#34;always\\u0026#34;`) ohne erneute Popup-Anzeige ausgeführt werden.**\\n\\n**Reproduktionsschritte:**\\n\\n1.  **Voraussetzung:** `tools.exec.ask` ist in `/root/.openclaw/openclaw.json` auf `\\u0026#34;always\\u0026#34;` gesetzt. `tools.elevated.enabled` ist ebenfalls auf `true` gesetzt und `allowFrom` für `webchat` (`openclaw-control-ui`) ist konfiguriert.\\n2.  **Schritt 1:** Führen Sie einen `exec`-Befehl aus, der ein Popup anfordert (z.B. `openclaw.exec(ask=\\u0026#34;always\\u0026#34;, command=\\u0026#34;cat /etc/os-release\\u0026#34;)`).\\n3.  **Schritt 2:** Der Benutzer genehmigt diesen Befehl über das angezeigte Popup.\\n4.  **Schritt 3:** Führen Sie **unmittelbar danach** einen *anderen* `exec`-Befehl aus (z.B. `openclaw.exec(ask=\\u0026#34;always\\u0026#34;, command=\\u0026#34;uptime\\u0026#34;)`).\\n\\n**Erwartetes Ergebnis:**\\nFür den Befehl in Schritt 3 sollte ebenfalls ein Freigabe-Popup erscheinen.\\n\\n**Tatsächliches Ergebnis:**\\nFür den Befehl in Schritt 3 erscheint **kein** Freigabe-Popup; der Befehl wird direkt ausgeführt.\\n\\n**Zusätzliche Beobachtungen:**\\n\\n*   **Zeitliche Verzögerung:** Wir haben Tests mit `sleep` zwischen dem ersten und zweiten Befehl durchgeführt (1, 5, 10, 30 Sekunden). Das Verhalten blieb konsistent: Auch nach 30 Sekunden Pause erschien kein zweites Popup. Dies deutet darauf hin, dass es kein einfaches Timeout-Problem ist.\\n*   **Reset-Verhalten:** Ein `docker restart openclaw` auf dem Host-System setzt das Verhalten temporär zurück. Nach einem Neustart erscheint das erste Popup (z.B. für den Reset der `exec-approvals.json`) wieder korrekt. Danach beginnt das inkonsistente Verhalten erneut.\\n*   **`exec-approvals.json`:** Die Datei `/root/.openclaw/exec-approvals.json` war während der Tests leer (`{}`), was ausschließt, dass eine pauschale `\\u0026#34;allow-always\\u0026#34;` Regel das Problem verursacht.\\n\\n**Umgebung:**\\n\\n*   **OpenClaw Version:** 2026.3.13 (61d171a)\\n*   **Betriebssystem des Hosts (Nexus):** AlmaLinux 9.4 (Seaborgium) (korrigiert nach deiner Rückmeldung)\\n*   **OpenClaw läuft in Docker (Debian-basiert).**\\n*   **Frontend:** OpenClaw Control UI (Webchat)\\n\\nDieses Verhalten untergräbt die beabsichtigte Sicherheitsfunktion von `ask=\\u0026#34;always\\u0026#34;`, da Befehle unbemerkt ausgeführt werden könnten.\\n\\nVielen Dank für Ihre Unterstützung bei der Untersuchung und Behebung dieses Problems.\\n\\nMit freundlichen Grüßen,\\n\\n[Dein Name / Tommy]\",\"state\":\"OPEN\",\"user\":{\"login\":\"Peilsender\"},\"comments\":1,\"created_at\":\"2026-03-21T18:04:11Z\",\"updated_at\":\"2026-03-21T18:15:34Z\"},{\"number\":51794,\"title\":\"secretref-env: not working for Discord token in channels.discord.token\",\"body\":\"## Description\\n\\nThe `secretref-env:` format is not working correctly for the Discord token in `channels.discord.token` configuration.\\n\\n## Steps to Reproduce\\n\\n1. Set Discord token in systemd service environment:\\n   ```\\n   Environment=OPENCLAW_DISCORD_TOKEN=MTQ2OTgyNjA0MjU0NDkxODYyMA.GvPdPl...\\n   ```\\n\\n2. Configure Discord channel with secretref-env:\\n   ```json\\n   \\u0026#34;channels\\u0026#34;: {\\n     \\u0026#34;discord\\u0026#34;: {\\n       \\u0026#34;enabled\\u0026#34;: true,\\n       \\u0026#34;token\\u0026#34;: \\u0026#34;secretref-env:OPENCLAW_DISCORD_TOKEN\\u0026#34;\\n     }\\n   }\\n   ```\\n\\n3. Start the gateway\\n\\n## Expected Behavior\\n\\nGateway should read the `OPENCLAW_DISCORD_TOKEN` environment variable and use its value to authenticate with Discord API.\\n\\n## Actual Behavior\\n\\nGateway returns 401 Unauthorized errors:\\n```\\n[discord] channel resolve failed; using config entries. Discord API /users/@me/guilds failed (401): 401: Unauthorized\\n```\\n\\n## Verification\\n\\n- Token is present in gateway process environment (verified via `/proc//environ`)\\n- Token works when tested directly with Discord API via curl\\n- Same token works when placed directly in config (not using secretref-env)\\n\\n## Workaround\\n\\nPlace token directly in config file:\\n```json\\n\\u0026#34;token\\u0026#34;: \\u0026#34;MTQ2OTgyNjA0MjU0NDkxODYyMA.GvPdPl...\\u0026#34;\\n```\\n\\n## Environment\\n\\n- OpenClaw version: 2026.3.13\\n- OS: Ubuntu 24.04.4 LTS\\n- Node: v22.22.0\\n\\n## Security Note\\n\\nThe workaround of putting tokens directly in config is less secure than using environment variables. This bug forces users to choose between a working Discord integration and better security practices.\",\"state\":\"OPEN\",\"user\":{\"login\":\"halointellicore\"},\"comments\":1,\"created_at\":\"2026-03-21T18:01:51Z\",\"updated_at\":\"2026-03-21T18:02:34Z\"},{\"number\":51793,\"title\":\"[Feature]: Multi-chat / tabbed sessions in webchat UI\",\"body\":\"## Feature Request\\n\\n**Problem:**\\nThe webchat UI currently supports only a single session. There\\u0026#39;s no way to have multiple parallel conversations like you can in ChatGPT, Codex, or Claude — where you have a sidebar of chats and can switch between them.\\n\\n**Desired behavior:**\\n- Tabbed or sidebar-based multi-session support in the webchat UI\\n- Ability to create new chats, switch between them, and see chat history\\n- Each chat should be an independent session with its own context\\n- Similar UX to Codex app\\u0026#39;s multi-conversation sidebar\\n\\n**Current workarounds:**\\n- Using different channels (webchat + Telegram) as separate sessions\\n- Spawning sub-agents for background tasks\\n- Opening multiple browser tabs (shares the same session)\\n\\n**Why it matters:**\\nPower users want to run multiple workstreams in parallel — e.g., one chat for coding, one for email/calendar, one for research — without context bleeding between them.\\n\\n---\\n_Filed via OpenClaw agent on behalf of user._\",\"state\":\"OPEN\",\"user\":{\"login\":\"aquaright1\"},\"comments\":2,\"created_at\":\"2026-03-21T17:54:21Z\",\"updated_at\":\"2026-03-21T18:00:40Z\"},{\"number\":51789,\"title\":\"Feature: `workspace.extraFiles` config for injecting additional bootstrap files\",\"body\":\"## Problem\\n\\nOpenClaw auto-injects a fixed set of top-level workspace files into the system prompt (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, etc.). There\\u0026#39;s no config option to inject additional files from subdirectories.\\n\\nThe current workaround is writing a custom `agent:bootstrap` hook that adds files to `context.bootstrapFiles`. This works but has a subtle bug: the bootstrap cache returns the **same array reference** on each call, so if a hook appends to it, the additions persist in the cache and accumulate on subsequent calls (compaction cycles, `/context` commands, etc.). We measured ~8x duplication, wasting 40-50K tokens per session.\\n\\nThe bundled `bootstrap-extra-files` hook avoids this by creating a fresh array, but there\\u0026#39;s no documentation warning custom hook authors about this behavior.\\n\\n## Proposed Solution\\n\\nAdd a config option like `agents.defaults.workspace.extraFiles` that accepts file paths or globs relative to the workspace:\\n\\n```json\\n{\\n  \\u0026#34;agents\\u0026#34;: {\\n    \\u0026#34;defaults\\u0026#34;: {\\n      \\u0026#34;workspace\\u0026#34;: {\\n        \\u0026#34;extraFiles\\u0026#34;: [\\n          \\u0026#34;prompts/CALENDARS.md\\u0026#34;,\\n          \\u0026#34;prompts/TECHNICAL.md\\u0026#34;,\\n          \\u0026#34;prompts/TODO.md\\u0026#34;\\n        ]\\n      }\\n    }\\n  }\\n}\\n```\\n\\nThese files would be resolved and injected alongside the built-in bootstrap files, using the same per-file and total character limits (`bootstrapMaxChars`, `bootstrapTotalMaxChars`).\\n\\n## Why This Helps\\n\\n1. **Eliminates the most common custom hook use case** — most bootstrap hooks just inject extra workspace files. A config option makes this declarative and safe.\\n2. **Avoids the cache mutation issue entirely** — users don\\u0026#39;t need to write hooks that interact with the cached array.\\n3. **Consistent with existing config patterns** — fits naturally alongside `bootstrapMaxChars` and `bootstrapTotalMaxChars`.\\n\\n## Alternatives Considered\\n\\n- **Return a copy from cache** — `resolveBootstrapFilesForRun` could return a copy instead of the original reference. Fixes the duplication but still requires boilerplate hooks for a simple \\u0026#34;include these files\\u0026#34; use case.\\n- **Documentation** — warn hook authors not to modify `context.bootstrapFiles` in place. Helps but doesn\\u0026#39;t eliminate the need for custom hooks.\\n\\n## Environment\\n\\n- OpenClaw 2026.3.2+\\n- Discovered while debugging 8x file duplication in a custom `agent:bootstrap` hook\",\"state\":\"OPEN\",\"user\":{\"login\":\"Maninae\"},\"created_at\":\"2026-03-21T17:42:17Z\",\"updated_at\":\"2026-03-21T17:42:17Z\"},{\"number\":51788,\"title\":\"Bug: Control UI prefixes xAI model IDs with \\u0026#39;anthropic/\\u0026#39; causing GatewayRequestError\",\"body\":\"## Summary\\n\\nWhen switching models via the Control UI (dropdown or `/model` command), xAI model IDs are sent to the gateway with an incorrect `anthropic/` prefix instead of `xai/`. This causes a `GatewayRequestError: model not allowed` for every xAI model.\\n\\n## Environment\\n\\n- **Version:** OpenClaw 2026.3.13 (61d171a)\\n- **OS:** macOS 26.3.1 (arm64)\\n- **Node:** 25.6.1\\n- **Channel:** webchat (Control UI)\\n\\n## Steps to Reproduce\\n\\n1. Configure xAI models in `agents.defaults.models` (e.g. `xai/grok-4.20-0309-reasoning`)\\n2. Add `xai:default` auth profile\\n3. Open Control UI and switch model via dropdown or `/model grok-4.2-r`\\n4. Observe error\\n\\n## Actual Behavior\\n\\nGateway receives model ID with wrong provider prefix:\\n\\n```\\nGatewayRequestError: model not allowed: anthropic/grok-4.20-0309-reasoning\\n```\\n\\nGateway logs (repeated across multiple attempts and UI reconnects):\\n\\n```\\n[ws] ⇄ res ✗ sessions.patch 6ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 7ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 12ms errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4.20-0309-reasoning\\n[ws] ⇄ res ✗ sessions.patch 8ms  errorCode=INVALID_REQUEST errorMessage=model not allowed: anthropic/grok-4-fast-non-reasoning\\n```\\n\\nThe pattern is consistent — **any** xAI model selected in the UI gets sent as `anthropic/` instead of `xai/`.\\n\\n## Expected Behavior\\n\\n`xai/grok-4.20-0309-reasoning` should be sent as-is, matching the allowlist entry.\\n\\n## Config (relevant excerpt)\\n\\n```json\\n\\u0026#34;agents\\u0026#34;: {\\n  \\u0026#34;defaults\\u0026#34;: {\\n    \\u0026#34;models\\u0026#34;: {\\n      \\u0026#34;xai/grok-4.20-0309-reasoning\\u0026#34;: { \\u0026#34;alias\\u0026#34;: \\u0026#34;grok-4.2-r\\u0026#34; },\\n      \\u0026#34;xai/grok-4.20-0309-non-reasoning\\u0026#34;: { \\u0026#34;alias\\u0026#34;: \\u0026#34;grok-4.2\\u0026#34; }\\n    }\\n  }\\n},\\n\\u0026#34;auth\\u0026#34;: {\\n  \\u0026#34;profiles\\u0026#34;: {\\n    \\u0026#34;anthropic:default\\u0026#34;: { \\u0026#34;provider\\u0026#34;: \\u0026#34;anthropic\\u0026#34;, \\u0026#34;mode\\u0026#34;: \\u0026#34;api_key\\u0026#34; },\\n    \\u0026#34;xai:default\\u0026#34;: { \\u0026#34;provider\\u0026#34;: \\u0026#34;xai\\u0026#34;, \\u0026#34;mode\\u0026#34;: \\u0026#34;api_key\\u0026#34; }\\n  }\\n}\\n```\\n\\n## Workaround\\n\\nNone found via UI. Clearing browser storage and hard refresh do not help. The bug appears to be in how the Control UI constructs the model ID before sending `sessions.patch` over WebSocket.\",\"state\":\"OPEN\",\"user\":{\"login\":\"neuvalbe\"},\"comments\":1,\"created_at\":\"2026-03-21T17:42:14Z\",\"updated_at\":\"2026-03-21T18:03:09Z\"},{\"number\":51787,\"title\":\"[Question] Is there interest in a managed hosting option for OpenClaw?\",\"body\":\"Hi, I\\u0026#39;ve been working on a managed hosting service for OpenClaw ([openclawup.com](https://openclawup.com)) that handles all the server setup, AI API keys, and deployment automatically.\\n\\nBefore I invest more time, I wanted to check with this community:\\n- Would a managed hosting option be useful for you or your team?\\n- What\\u0026#39;s the biggest pain point when self-hosting OpenClaw?\\n\\n**What it does (so far):**\\n- One-click deploy to Telegram or Discord (~60 seconds)\\n- 9 AI models included (Claude, GPT, Gemini, DeepSeek, etc.) — no API keys needed\\n- Free 3-day trial, no credit card required\\n- You can try the AI right on the homepage before signing up\\n\\nI\\u0026#39;m not trying to spam — genuinely looking for feedback from people who actually use OpenClaw. If this isn\\u0026#39;t the right place for this kind of post, happy to remove it.\\n\\nThanks!\",\"state\":\"OPEN\",\"user\":{\"login\":\"wolfqing\"},\"comments\":1,\"created_at\":\"2026-03-21T17:40:35Z\",\"updated_at\":\"2026-03-21T18:15:56Z\"},{\"number\":51785,\"title\":\"WhatsApp outbound send to new contact fails despite linked session\",\"body\":\"## Bug report — WhatsApp outbound send to new contact fails despite linked session\\n\\n**Context**\\n- OpenClaw version: `2026.3.13`\\n- OS: Windows 11\\n- Gateway local in loopback mode\\n- WhatsApp account: `default`\\n- inbound WhatsApp works with my own number\\n- goal: send an outbound WhatsApp message to a new contact (`+33695994586`)\\n\\n**Symptoms**\\n- inbound WhatsApp works\\n- `openclaw status --deep` often shows:\\n  - `WhatsApp | LINKED`\\n- logs also show:\\n  - `Linked after restart; web session ready`\\n  - `Listening for personal WhatsApp inbound messages`\\n\\nBut outbound sends via the native `message` tool fail with inconsistent errors.\\n\\n**Errors observed**\\n1. With E.164 target:\\n- `Error: Delivering to WhatsApp requires target `\\n\\nTested with:\\n- `+33695994586`\\n- `33695994586`\\n- `+33695994586@s.whatsapp.net`\\n- `33695994586@c.us`\\n\\n2. With `targets` variant:\\n- `Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.`\\n\\n**Important**\\n- the account appears **linked**\\n- inbound works\\n- gateway is reachable\\n- outbound/listener state appears inconsistent with linked state\\n\\n**What we already did**\\n- repaired semantic memory (switched to Gemini embeddings)\\n- installed Git\\n- installed Python + tzdata\\n- set up Gmail digest scripts\\n- explicitly exposed the `message` tool via config:\\n  - `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`\\n- set session visibility:\\n  - `tools.sessions.visibility = \\u0026#34;agent\\u0026#34;`\\n- restarted the gateway multiple times\\n- attempted WhatsApp relink:\\n  - `openclaw channels login --channel whatsapp --account default`\\n- relink output:\\n  - `✅ Linked! Credentials saved for future sends.`\\n\\n**Findings**\\n- before config changes, `message` tool was not exposed in this session\\n- after adding `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`, the native `message` tool became available\\n- `sessions_send` can reach another OpenClaw session, but does not guarantee a real external WhatsApp delivery\\n- the issue now seems isolated to:\\n  - WhatsApp target validation in `message.send`\\n  - and/or outbound listener state detection after relink\\n\\n**Relevant config**\\n- `tools.profile = \\u0026#34;coding\\u0026#34;`\\n- `tools.alsoAllow = [\\u0026#34;message\\u0026#34;]`\\n- `tools.sessions.visibility = \\u0026#34;agent\\u0026#34;`\\n- `channels.whatsapp.enabled = true`\\n- `channels.whatsapp.dmPolicy = \\u0026#34;allowlist\\u0026#34;`\\n- `channels.whatsapp.allowFrom = [\\u0026#34;+33619994507\\u0026#34;]`\\n\\n**Hypothesis**\\nThere may be a bug in one or more of:\\n- WhatsApp E.164 target validation in `message.send`\\n- detection of active WhatsApp Web listener after relink\\n- divergence between inbound linked state and outbound send readiness\\n\",\"state\":\"OPEN\",\"user\":{\"login\":\"kraffes\"},\"comments\":1,\"created_at\":\"2026-03-21T17:30:50Z\",\"updated_at\":\"2026-03-21T17:36:05Z\"}],\"totalCount\":8763,\"pageInfo\":{\"hasNextPage\":true,\"hasPreviousPage\":false,\"startCursor\":\"Y3Vyc29yOnYyOpK5MjAyNi0wMy0yMVQxMToxMDoxNi0wNzowMM71KytV\",\"endCursor\":\"Y3Vyc29yOnYyOpK5MjAyNi0wMy0yMVQxMDozMDo1MC0wNzowMM71KVel\"}}"}]}
{"type":"assistant","message":{"model":"claude-sonnet-4-6","id":"msg_014JehjDg2WRZASN6hX6xAGh","type":"message","role":"assistant","content":[{"type":"text","text":"The most recent open issue in **openclaw/openclaw** is:\n\n**#51800** — \"Web UI: onAttachmentsChange callback is undefined, paste image not delivered to Gateway\"\n\nCreated on 2026-03-21 by `lulu-claude`."}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":1,"cache_creation_input_tokens":7469,"cache_read_input_tokens":40990,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":7469},"output_tokens":1,"service_tier":"standard","inference_geo":"not_available"},"context_management":null},"parent_tool_use_id":null,"session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","uuid":"ebd02cae-57b8-4553-8c56-cd28ee0d2a65"}
{"type":"result","subtype":"success","is_error":false,"duration_ms":7941,"duration_api_ms":7485,"num_turns":2,"result":"The most recent open issue in **openclaw/openclaw** is:\n\n**#51800** — \"Web UI: onAttachmentsChange callback is undefined, paste image not delivered to Gateway\"\n\nCreated on 2026-03-21 by `lulu-claude`.","stop_reason":"end_turn","session_id":"cf92efe0-6762-49b2-8029-04c689e1302f","total_cost_usd":0.05628975,"usage":{"input_tokens":4,"cache_creation_input_tokens":7469,"cache_read_input_tokens":81980,"output_tokens":245,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":7469,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{"claude-sonnet-4-6":{"inputTokens":4,"outputTokens":245,"cacheReadInputTokens":81980,"cacheCreationInputTokens":7469,"webSearchRequests":0,"costUSD":0.05628975,"contextWindow":200000,"maxOutputTokens":32000}},"permission_denials":[],"fast_mode_state":"off","uuid":"385b6018-32fe-4ed9-9e9e-74c7a7ed1a34"}
