Merged
Conversation
…enclaw#24696) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: d6d4b43 Co-authored-by: gumadeiras <5599352+gumadeiras@users.noreply.github.com> Co-authored-by: gumadeiras <5599352+gumadeiras@users.noreply.github.com> Reviewed-by: @gumadeiras
…rror The generic "node command not allowed" error gives no indication of why the command was rejected, making it hard to diagnose issues (e.g. running `nodes notify` against a Linux node that does not declare `system.notify`). Include the rejection reason and node platform in the error message so callers can tell whether the command is not supported by the node, not in the platform allowlist, or the node did not advertise its capabilities. Fixes openclaw#24616 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> (cherry picked from commit e3d7461)
(cherry picked from commit e682a76)
…tension The extension relay server authenticates using an HMAC-SHA256 derived token (`openclaw-extension-relay-v1:<port>`), but the Chrome extension was sending the raw gateway token. This caused both the WebSocket connection and the options page validation to fail with 401 Unauthorized. Additionally, the options page validation request triggered a CORS preflight (due to the custom `x-openclaw-relay-token` header) which the relay rejects because OPTIONS requests lack auth headers. The options page now delegates the check to the background service worker which has host_permissions and bypasses CORS preflight. Fixes openclaw#23842 Co-authored-by: Cursor <cursoragent@cursor.com> (cherry picked from commit bbc654b)
(cherry picked from commit 1edf957)
(cherry picked from commit 485a55b)
…penclaw#22327) Merged via /review-pr -> /prepare-pr -> /merge-pr. Prepared head SHA: 2f02ec9 Co-authored-by: therk <901920+therk@users.noreply.github.com> Co-authored-by: gumadeiras <5599352+gumadeiras@users.noreply.github.com> Reviewed-by: @gumadeiras
Co-authored-by: Isis Anisoptera <github@lotuswind.net>
Co-authored-by: Lucian Feraru <1ucian@users.noreply.github.com>
Co-authored-by: aidiffuser <aidiffuser@users.noreply.github.com>
Co-authored-by: Axel Svensson <svenssonaxel@users.noreply.github.com>
Co-authored-by: avirweb <avirweb@users.noreply.github.com>
…uncation repairToolUseResultPairing was gated behind !isOpenAi, skipping orphaned tool_result cleanup for OpenAI providers. When limitHistoryTurns truncated conversation history, tool_result messages whose matching tool_call was before the truncation point survived and were sent as function_call_output items with stale call_id references. OpenAI rejects these with: "No tool call found for function call output with call_id ..." Enable the repair universally — all providers need it after truncation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> (cherry picked from commit 97b065a)
…penAI The previous test asserted that OpenAI-responses sessions would NOT get synthetic tool results for orphaned tool calls. With repairToolUseResultPairing now running universally, the correct behavior is that orphaned tool calls get a synthetic tool_result — matching what OpenAI actually requires. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> (cherry picked from commit 2edb0ff)
…odel
The 'auto' model on OpenRouter dynamically routes to any underlying model
OpenRouter selects, including reasoning-required endpoints. Previously,
OpenClaw would unconditionally inject `reasoning.effort: "none"` into
every request when the thinking level was "off", which causes a 400 error
on models where reasoning is mandatory and cannot be disabled.
Root cause:
- openrouter/auto has reasoning: false in the built-in catalog
- With thinking level "off", createOpenRouterWrapper injects
`reasoning: { effort: "none" }` via mapThinkingLevelToOpenRouterReasoningEffort
- For any OpenRouter-routed model that requires reasoning this results in:
"400 Reasoning is mandatory for this endpoint and cannot be disabled"
- The reasoning: false is then persisted back to models.json on every
ensureOpenClawModelsJson call, so manually removing it has no lasting effect
Fix:
- In applyExtraParamsToAgent, when provider is "openrouter" and the model
id is "auto", pass undefined as thinkingLevel to createOpenRouterWrapper
so no reasoning.effort is injected at all, letting OpenRouter's upstream
model handle it natively
- Add an explanatory comment in buildOpenrouterProvider clarifying that the
reasoning: false catalog value does NOT cause effort injection for "auto"
Users who need explicit reasoning control should target a specific model
id (e.g. openrouter/deepseek/deepseek-r1) rather than the auto router.
Fixes openclaw#24851
(cherry picked from commit aa55439)
In trusted-proxy mode, sharedAuthResult is null because hasSharedAuth only triggers for token/password in connectParams.auth. But the primary auth (authResult) already validated the trusted-proxy — the connection came from a CIDR in trustedProxies with a valid userHeader. This IS shared auth semantically (the proxy vouches for identity), so operator connections should be able to skip device identity. Without this fix, trusted-proxy operator connections are rejected with "device identity required" because roleCanSkipDeviceIdentity() sees sharedAuthOk=false. (cherry picked from commit e87048a)
(cherry picked from commit bddeb1f)
…close (cherry picked from commit df827c3)
When reasoningLevel is 'on', reasoning content was being sent as a visible message to WhatsApp and other non-Telegram channels via two paths: 1. Block reply: emitted via onBlockReply in handleMessageEnd 2. Final payloads: added to replyItems in buildEmbeddedRunPayloads Telegram has its own dispatch path (bot-message-dispatch.ts) that splits reasoning into a dedicated lane and handles suppression. The generic dispatch-from-config.ts path used by WhatsApp, web, etc. had no such filtering. Fix: - Add isReasoning?: boolean flag to ReplyPayload - Tag reasoning payloads at both emission points - Filter isReasoning payloads in dispatch-from-config.ts for both block reply and final reply paths Telegram is unaffected: it uses its own deliver callback that detects reasoning via the 'Reasoning:\n' prefix and routes to a separate lane. Fixes openclaw#24954
When `includeReasoning` is active (or `reasoningLevel` falls back to the model default), the agent emits reasoning blocks as separate reply payloads prefixed with "Reasoning:\n". Matrix has no dedicated reasoning lane, so these internal thinking traces leak into the chat as regular user-visible messages. Filter out pure-reasoning payloads (those starting with "Reasoning:\n" or a `<thinking>` tag) before delivery so internal reasoning never reaches the Matrix room. Fixes openclaw#24411 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Verify that deliverMatrixReplies skips replies whose text starts with "Reasoning:\n" or opens with <thinking>/<think>/<antthinking> tags, while still delivering all normal replies. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When streamMode is "partial", reasoning/thinking block content can leak into the Discord draft preview because the partial text is forwarded to the draft stream without filtering. Apply `stripReasoningTagsFromText` before updating the draft and skip pure-reasoning messages (those starting with "Reasoning:\n") so internal thinking traces never reach the user-visible preview. Fixes openclaw#24532 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ream Verify that partial stream updates containing <thinking> tags are stripped before reaching the draft preview, and that pure "Reasoning:\n" partials are suppressed entirely. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Attribution-only commit for the bot-authored upstream patch landed from openclaw#24705.
|
Important Review skippedToo many files! This PR contains 298 files, which is 148 over the limit of 150. ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (298)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Describe the problem and fix in 2–5 bullets:
Change Type (select all)
Scope (select all touched areas)
Linked Issue/PR
User-visible / Behavior Changes
List user-visible changes (including defaults/config).
If none, write
None.Security Impact (required)
Yes/No)Yes/No)Yes/No)Yes/No)Yes/No)Yes, explain risk + mitigation:Repro + Verification
Environment
Steps
Expected
Actual
Evidence
Attach at least one:
Human Verification (required)
What you personally verified (not just CI), and how:
Compatibility / Migration
Yes/No)Yes/No)Yes/No)Failure Recovery (if this breaks)
Risks and Mitigations
List only real risks for this PR. Add/remove entries as needed. If none, write
None.