openclaw - ✅(Solved) Fix [Feature]: support cap thinking-event when websocket connect [2 pull requests, 1 comments, 1 participants]

caesargattuso · 2026-03-17T12:29:01Z

[openclaw] - Problem 1 gateway never received thinking tokens : streamReasoning was initialized as reasoningMode === "stream" && typeof onReasoningStream === "… - **Problem 1 (gateway never received thinking tokens):** `streamReasoning` was initialized as `reasoningMode === "stream" && typeof onReasoningStream === "function"`. Gateway WebSocket runs never supply `onReasoningStream`, so the flag was always `false` and `emitAgentEvent` for `stream: "thinking"` was never called — even when the session had `/reasoning stream` configured. - **Problem 2 (delta === text on every event):** The delta was computed by `formatted.startsWith(prior)`, but `formatReasoningMessage` wraps each line in `_…_` markdown italics, breaking prefix matching (e.g. `"_Checking files_"` is not a prefix of `"_Checking files done_"`). When the check failed, the code fell back to `delta = formatted`, making every event's `delta` equal to `text`. Additionally, when a pure incremental chunk was passed (e.g. native `thinking_delta` fallback), `lastStreamedReasoning` was set to just the chunk instead of the accumulated text, corrupting all future deltas. - **Problem 3 (no cap-gated subscription for thinking events):** Thinking events previously fell through the generic `broadcast("agent", …)` path (same as all non-tool events), delivering raw reasoning tokens to every connected client with no opt-in mechanism. - **What changed:** Added a `thinking-events` client capability; thinking events are now routed exclusively to registered cap subscribers via `broadcastToConnIds`; `nodeSendToSession` is guarded against thinking events; delta computation is based on raw (unformatted) accumulated text; `streamReasoning` is decoupled from `onReasoningStream`. - **What did NOT change:** Tool-event routing, session lifecycle, chat delta throttling, `nodeSendToSession` behavior for all non-thinking streams, and the external format of `text` in thinking events (still `formatReasoningMessage` output). # PR #50787: feat(gateway): support cap thinking-event when websocket connect - Repository: openclaw/openclaw - Author: caesargattuso - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/50787 ## Description (problem / solution / changelog) ## Summary - **Problem 1 (gateway never received thinking tokens):** `streamReasoning` was initialized as `reasoningMode === "stream" && typeof onReasoningStream === "function"`. Gateway WebSocket runs never supply `onReasoningStream`, so the flag was always `false` and `emitAgentEvent` for `stream: "thinking"` was never called — even when the session had `/reasoning stream` configured. - **Problem 2 (delta === text on every event):** The delta was computed by `formatted.startsWith(prior)`, but `formatReasoningMessage` wraps each line in `_…_` markdown italics, breaking prefix matching (e.g. `"_Checking files_"` is not a prefix of `"_Checking files done_"`). When the check failed, the code fell back to `delta = formatted`, making every event's `delta` equal to `text`. Additionally, when a pure incremental chunk was passed (e.g. native `thinking_delta` fallback), `lastStreamedReasoning` was set to just the chunk instead of the accumulated text, corrupting all future deltas. - **Problem 3 (no cap-gated subscription for thinking events):** Thinking events previously fell through the generic `broadcast("agent", …)` path (same as all non-tool events), delivering raw reasoning tokens to every connected client with no opt-in mechanism. - **What changed:** Added a `thinking-events` client capability; thinking events are now routed exclusively to registered cap subscribers via `broadcastToConnIds`; `nodeSendToSession` is guarded against thinking events; delta computation is based on raw (unformatted) accumulated text; `streamReasoning` is decoupled from `onReasoningStream`. - **What did NOT change:** Tool-event routing, session lifecycle, chat delta throttling, `nodeSendToSession` behavior for all non-thinking streams, and the external format of `text` in thinking events (still `formatReasoningMessage` output). ## Change Type (select all) - [x] Bug fix - [x] Feature ## Scope (select all touched areas) - [x] Gateway / orchestration - [x] API / contracts ## Linked Issue/PR - Closes #48995 - Related #48995 ## User-visible / Behavior Changes - Clients that advertise `caps: ["thinking-events"]` in their `connect` payload now receive `agent` events with `stream: "thinking"` containing `{ text: , delta: }` in real time when the session has `reasoningLevel: "stream"`. - Clients that do **not** advertise this cap no longer receive thinking-stream tokens at all (previously they received them via the general broadcast). - `delta` is now always the incremental raw text added since the last event, not a repeat of `text`. ## Security Impact (required) - New permissions/capabilities? **Yes** — adds `thinking-events` cap; reasoning tokens are now opt-in rather than broad

openclaw2026-03-17 12:29:01

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#48995•Fetched 2026-04-08 00:50:01

View on GitHub

Comments

Participants

Timeline

Reactions

Author

caesargattuso

Participants

caesargattuso

Timeline (top)

cross-referenced ×2commented ×1labeled ×1renamed ×1

Problem 1 (gateway never received thinking tokens): streamReasoning was initialized as reasoningMode === "stream" && typeof onReasoningStream === "function". Gateway WebSocket runs never supply onReasoningStream, so the flag was always false and emitAgentEvent for stream: "thinking" was never called — even when the session had /reasoning stream configured.
Problem 2 (delta === text on every event): The delta was computed by formatted.startsWith(prior), but formatReasoningMessage wraps each line in _…_ markdown italics, breaking prefix matching (e.g. "_Checking files_" is not a prefix of "_Checking files done_"). When the check failed, the code fell back to delta = formatted, making every event's delta equal to text. Additionally, when a pure incremental chunk was passed (e.g. native thinking_delta fallback), lastStreamedReasoning was set to just the chunk instead of the accumulated text, corrupting all future deltas.
Problem 3 (no cap-gated subscription for thinking events): Thinking events previously fell through the generic broadcast("agent", …) path (same as all non-tool events), delivering raw reasoning tokens to every connected client with no opt-in mechanism.
What changed: Added a thinking-events client capability; thinking events are now routed exclusively to registered cap subscribers via broadcastToConnIds; nodeSendToSession is guarded against thinking events; delta computation is based on raw (unformatted) accumulated text; streamReasoning is decoupled from onReasoningStream.
What did NOT change: Tool-event routing, session lifecycle, chat delta throttling, nodeSendToSession behavior for all non-thinking streams, and the external format of text in thinking events (still formatReasoningMessage output).

Error Message

Risk: thinkingEventRecipients registry entries accumulate if markFinal is not called on error paths.
Mitigation: markFinal is called for both lifecyclePhase === "end" and lifecyclePhase === "error", matching the existing toolEventRecipients cleanup pattern; the TTL-based pruning in createThinkingEventRecipientRegistry provides a backstop.

Root Cause

Events with stream: "thinking" arrive in real time.
Each event's data.delta is the new incremental raw thinking text (e.g. " because", not the full accumulated string).
Each event's data.text is the fully formatted accumulated thinking string (e.g. "Reasoning:\n_Because it helps_").

extent analysis

Fix Plan

To implement the real-time thinking stream support in OpenClaw Gateway, follow these steps:

Add thinking-events capability:
- In src/gateway/protocol/client-info.ts, add THINKING_EVENTS: "thinking-events" to GATEWAY_CLIENT_CAPS.
- Clients must declare this capability in their connect frame:
```
{
  "connect": {
    "caps": ["thinking-events"],
    "reasoningLevel": "stream"
  }
}
```
Modify pi-embedded-subscribe.ts:
- Remove the onReasoningStream guard in emitReasoningStream.
- Emit raw delta/text to WS, keeping formatted output for onReasoningStream.
Update server-chat.ts and server-runtime-state.ts:
- Route stream: "thinking" events to registered connIds only (not broadcast).
- Instantiate thinkingEventRecipients registry.
Wire registry through context in server.impl.ts:
- Add registerThinkingEventRecipient to context interface in server-methods/types.ts.
Register connId on run start:
- In server-methods/chat.ts and server-methods/agent.ts, register connId when the thinking-events cap is declared.
Add reasoningDefault to agent config:
- In config/types.agent-defaults.ts, add reasoningDefault to AgentDefaultsConfig.
- In config/zod-schema.agent-defaults.ts, add Zod validation for reasoningDefault.
Update directive handling and reply logic:
- In auto-reply/reply/directive-handling.levels.ts and auto-reply/reply/get-reply-directives.ts, read agentCfg.reasoningDefault as fallback.

Example Code Snippets

// src/gateway/protocol/client-info.ts
export const GATEWAY_CLIENT_CAPS = {
  //...
  THINKING_EVENTS: "thinking-events",
};

// src/agents/pi-embedded-subscribe.ts
function emitReasoningStream(delta, text) {
  // Removed onReasoningStream guard
  emitAgentEvent({ stream: "thinking", data: { delta, text } });
}

// src/gateway/server-chat.ts
function handleThinkingEvent(event) {
  const recipients = thinkingEventRecipients.get(event.stream);
  if (recipients) {
    recipients.forEach((connId) => {
      // Send event to registered connIds
      sendEventToConnId(connId, event);
    });
  }
}

Verification

To verify the fix, test the following scenarios:

Clients declaring the thinking-events capability receive stream: "thinking" events in real-time.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #ssr #installation #tensor shape #autograd error #model download #tokenizer error #prompt formatting #chain error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Feature]: support cap thinking-event when websocket connect [2 pull requests, 1 comments, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

Risks and Mitigations

PR fix notes

PR #50787: feat(gateway): support cap thinking-event when websocket connect

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

PR #54821: feat: support capability subscription thinking events

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

extent analysis

Fix Plan

Example Code Snippets

Verification

Still need to ship something?

RELATED_DISCOVERY

TRENDING