Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: `parseStandalonePlainTextToolCallBlocks` doesn't recognize OpenAI Harmony-format tool calls (gpt-oss-120b on LM Studio) [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78326•Fetched 2026-05-07 03:38:10
View on GitHub
Comments
1
Participants
2
Timeline
11
Reactions
2
Author
kstrat2001kstrat2001
Participants
clawsweeper[bot]clawsweeper[bot]kstrat2001kstrat2001
Timeline (top)
referenced ×3cross-referenced ×2mentioned ×2subscribed ×2

On LM Studio with gpt-oss-120b, agent dispatches sometimes terminate after the model's first turn with zero tool invocations because parseStandalonePlainTextToolCallBlocks (in src/plugin-sdk/tool-payload.ts) only recognizes bracket-style blocks and returns null for the model's native Harmony commentary-channel tool-call syntax, defeating the LM Studio extension's plain-text recovery path (wrapLmstudioPlainTextToolCalls in extensions/lmstudio/src/index.ts).

Error Message

tool invocations and no observable error message; the user sees an

Root Cause

On LM Studio with gpt-oss-120b, agent dispatches sometimes terminate after the model's first turn with zero tool invocations because parseStandalonePlainTextToolCallBlocks (in src/plugin-sdk/tool-payload.ts) only recognizes bracket-style blocks and returns null for the model's native Harmony commentary-channel tool-call syntax, defeating the LM Studio extension's plain-text recovery path (wrapLmstudioPlainTextToolCalls in extensions/lmstudio/src/index.ts).

Fix Action

Fix / Workaround

On LM Studio with gpt-oss-120b, agent dispatches sometimes terminate after the model's first turn with zero tool invocations because parseStandalonePlainTextToolCallBlocks (in src/plugin-sdk/tool-payload.ts) only recognizes bracket-style blocks and returns null for the model's native Harmony commentary-channel tool-call syntax, defeating the LM Studio extension's plain-text recovery path (wrapLmstudioPlainTextToolCalls in extensions/lmstudio/src/index.ts).

For an end-to-end repro (requires LM Studio + gpt-oss-120b loaded):

  1. lms load gpt-oss-120b --context-length 102400
  2. In ~/.openclaw/openclaw.json: models.providers.lmstudio.api = "openai-completions"
  3. Configure any agent with a moderately heavy system prompt (e.g. bundled qa-style workspace, ~25K+ chars + ~15+ declared tools).
  4. Dispatch a tool-using request via openclaw agent --agent <name> --json --message "<request that requires a tool>".
  5. Observe in ~/.openclaw/agents/<name>/sessions/*.jsonl: assistant message content includes a text block of the form "commentary to=<tool> code {<json>}" followed by stopReason: "stop", zero toolCall blocks, run terminates without performing work.

Consequence chain (verified by walking the bundled JS during dispatches):

  1. wrapLmstudioPlainTextToolCalls receives null from the parser and therefore does not promote the message.
  2. The assistant message reaches the OpenClaw runtime as plain text content with stopReason: "stop".
  3. The agent loop terminates after the model's first turn — zero tool invocations, no work performed.
  4. CLI exit code is 0 — the user sees an apparently-successful dispatch that produced nothing.

PR fix notes

PR #78339: fix(plugin-sdk): recognize Harmony-format plain-text tool calls in parser [AI-assisted]

Description (problem / solution / changelog)

🤖 AI-assisted (built with Codex via Hermes orchestration). Test level: fully tested. Prompt summary available on request.

Summary

  • Problem: parseStandalonePlainTextToolCallBlocks only recognized bracket-style tool calls ([toolname]\n{json}\n[/toolname]), causing LM Studio's plain-text tool call recovery to fail silently when models emit OpenAI Harmony format
  • Why it matters: The agent loop terminated after the model's first turn with zero tool invocations and exit code 0, making LM Studio + gpt-oss-120b completely unusable for tool calling
  • What changed: Added parseHarmonyOpening() and consumeHarmonyTrailing() as fallback parsers in parsePlainTextToolCallBlockAt() when bracket-style parsing returns null
  • What did NOT change (scope boundary): The existing bracket-style parser path is completely unchanged — harmony parsing is only attempted when the input does not start with [

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Plugin SDK

Linked Issue/PR

  • Closes #78326
  • This PR fixes a bug or regression

Root Cause

  • Root cause: parseStandalonePlainTextToolCallBlocks in src/plugin-sdk/tool-payload.ts only recognized bracket-style plain-text tool call blocks. When gpt-oss-120b on LM Studio emits tool calls in OpenAI Harmony format (commentary to=read code {"path":...}), the parser returned null, causing the LM Studio extension's parseLmstudioPlainTextToolCalls recovery path to fail silently
  • Missing detection / guardrail: No tests existed for non-bracket tool call formats in the shared parser
  • Contributing context (if known): The Harmony format is specific to certain models on LM Studio and was not anticipated when the original parser was written

Regression Test Plan

  • Coverage level that should have caught this:
    • Unit test
  • Target test or file: src/plugin-sdk/tool-payload.test.ts
  • Scenario the test should lock in: Harmony-format tool calls (bare channel keywords, delimited form, trailing delimiters) are correctly parsed; malformed inputs (missing to=, missing code keyword, unknown channel) return null
  • Why this is the smallest reliable guardrail: Parser unit tests directly verify the parsing logic without needing LM Studio or a specific model
  • Existing test that already covers this (if any): 3 existing bracket-style tests pass unchanged
  • If no new test is added, why not: N/A — 11 new tests added

User-visible / Behavior Changes

  • LM Studio users with models that emit Harmony-format tool calls (e.g., gpt-oss-120b) will now have their tool calls correctly parsed and executed instead of silently failing

Security Impact (required)

  • New permissions/capabilities? No
  • This is a purely additive parser enhancement — no new input vectors, no changes to tool execution policy, no changes to how parsed tool calls are promoted or invoked. The existing bracket-style parser path is untouched.

Changed files

  • src/plugin-sdk/tool-payload.test.ts (modified, +94/-1)
  • src/plugin-sdk/tool-payload.ts (modified, +94/-7)

PR #78427: fix(lmstudio): handle OpenAI Harmony plain-text tool calls (parser + prefix buffer + strip)

Description (problem / solution / changelog)

Fixes the agent-loop-terminates-silently regression reported in issue #78326, where gpt-oss-120b on LM Studio emits OpenAI Harmony tool-call syntax as plain text and the OpenClaw recovery path fails to recognise it.

Root cause

When LM Studio's chat-template wrapping fails to translate gpt-oss-style models' native OpenAI Harmony tool-call output back into structured tool_calls, the harmony commentary syntax leaks through as plain assistant text. The OpenClaw parser, prefix buffer, and strip path all only recognised the bracket form ([name]\n{json}\n[/name]), so:

  1. parseStandalonePlainTextToolCallBlocks returned null, the LM Studio recovery path fell over, and the agent loop terminated with zero tool invocations and exit code 0.
  2. Even with a parser fix in place, couldStillBePlainTextToolCall in extensions/lmstudio/src/stream.ts only buffered text starting with [. Harmony text starting with commentary/analysis/final or <|channel|> was flushed to the user-visible stream before done-time promotion ran, so harmony content briefly leaked even on a successful promotion.
  3. stripPlainTextToolCallBlocks short-circuited on a bracket-only regex, leaving harmony-shaped blocks visible in fallback / persisted-text paths.

ClawSweeper called out (1) and (2) on the bug report; the bot's "best possible solution" was a two-piece fix plus a user-facing changelog. This PR delivers all three pieces.

Fix

PathChange
src/plugin-sdk/tool-payload.tsNew parseHarmonyOpening recognises bare-channel (commentary to=<name> code {…}) and delimited (<|channel|>commentary to=<name> code<|message|>{…}) shapes; parsePlainTextToolCallBlockAt falls through to it when bracket parsing returns null. Trailing <|end|>/<|return|>/<|message|> consumed. functions.<name> prefix stripped.
src/plugin-sdk/tool-payload.tsNew shared helpers containsPlainTextToolCallOpening (cheap detection) and couldStillBePlainTextToolCallPrefix (streaming-side predicate).
src/plugin-sdk/tool-payload.tsstripPlainTextToolCallBlocks short-circuit now uses the shared detection helper, so harmony-shaped blocks are removed from persisted/fallback text.
extensions/lmstudio/src/stream.tscouldStillBePlainTextToolCall delegates to the shared predicate, so harmony text is buffered and replaced by promoted toolcall_* events at done instead of leaking through to the visible stream.
CHANGELOG.mdUnreleased entry under ### Changes.

Bracket-style code paths are unchanged — harmony parsing is only attempted when bracket parsing returns null, and the prefix buffer remains permissive in the same way it has been (a buffer whose contents end up not being a tool call is flushed at done).

Tests

  • src/plugin-sdk/tool-payload.test.ts — 36 tests (3 existing + 33 new), including a regression test using verbatim wild output captured from gpt-oss-120b on LM Studio.
  • extensions/lmstudio/src/stream.test.ts — 14 wrapper tests (10 existing + 4 new), exercising the actual wrapLmstudioInferencePreload pipeline end-to-end with real pi-ai event types. Asserts harmony text is held back, replaced by toolcall_start/toolcall_delta events, and the done event carries a structured toolUse message.
  • pnpm test:extension lmstudio — 80 tests pass.
  • pnpm test:contracts — 29 channel + 768 plugin tests pass.
  • pnpm check (preflight + typecheck + lint + policy guards) — exit 0.

Real behavior proof

  • Behavior or issue addressed: Agent loop terminates silently with zero tool invocations when gpt-oss-120b on LM Studio emits OpenAI Harmony tool-call syntax as plain text instead of structured tool_calls (issue #78326). After fix, the same harmony output is recognised, the tool call is promoted at done, and harmony text is no longer streamed to the visible output before promotion.

  • Real environment tested: macOS Darwin arm64 25.4.0, Node 24.13.0, OpenClaw 2026.5.4, LM Studio with gpt-oss-120b loaded at 102K context via the openai-completions adapter at http://localhost:1234/v1.

  • Exact steps or command run after this patch:

    1. pnpm build against the harmony-format-tool-calls branch.
    2. pnpm gateway:dev on port 19001 (OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_PORT=19001) — gateway serves from this branch's freshly built dist/.
    3. openclaw --dev agent --agent qa --json --timeout 240 --message "Use the read tool to fetch lines 1-50 of …/companyService.test.ts and list the it() test names." — real LM Studio + gpt-oss-120b dispatch.
    4. node parser-proof-vanilla.mjs and node parser-proof-branch.mjs against three real harmony emissions captured live in ~/.openclaw/logs/gateway.log earlier today (runIds 32506c61-…, 670856e5-…, 8c81643b-… at lines 4118070, 4118105, 4118140 of the source log — only producible by a live model).

  • Evidence after fix (copied live output):

    Bundle SHA-256 hashes (this branch's freshly built bundle vs. vanilla npm-published 2026.5.4):

    $ shasum -a 256 dist/tool-payload-DGDW5vFU.js \
                /opt/homebrew/lib/node_modules/openclaw/dist/tool-payload-BItVC3Jn.js.bak
395ea00a1b42b3b6b807531c0830140b1251f3c0f2b533240968c836016d52cb  dist/tool-payload-DGDW5vFU.js  (this branch)
edcafe007cc62e32ce0dcd08fe029400a567b150418a79cc8c8cd1fefaf511ec  …BItVC3Jn.js.bak  (vanilla npm 2026.5.4)

    Real harmony emissions captured in ~/.openclaw/logs/gateway.log:

    $ grep -n "commentary to=" ~/.openclaw/logs/gateway.log
4118070:commentary to=exec code {
4118105:commentary to=exec code {
4118140:commentary to=read code {"path":"…refreshTokenService.test.ts","line_start":1,"line_end":400}
runId=32506c61-aa0f-478c-9b54-16561970598f   2026-05-06T12:10:30+08
runId=670856e5-a3ad-4d96-933e-43874a17c0cc   2026-05-06T12:12:22+08
runId=8c81643b-ee24-4ae3-a99e-fe0dcc1635c4   2026-05-06T12:20:38+08

    Same captured strings fed through the vanilla bundle vs. this branch's freshly built bundle:

    vanilla npm bundle:   0 of 3 emissions parse → agent terminates silently (the bug)
this branch's bundle: 3 of 3 emissions parse, plus strip 3/3, prefix-buffer 6/6,
                      detect 4/4 on real captured input

    Live agent dispatch against an OpenClaw gateway built from this branch (pnpm gateway:dev on port 19001, real LM Studio + gpt-oss-120b):

    runId:        b2a85599-75b8-4f5f-af9d-be7319c5bf29
status:       ok
toolSummary:  { calls: 2, tools: ["read"], failures: 0 }
durationMs:   26091
finishReason: stop

  • Observed result after fix: harmony tool-call output is now recognised by the parser, held back by the prefix-buffer predicate during streaming, and promoted to a structured toolUse at done. The live dispatch completes with status=ok, two read tool invocations, zero failures, and a clean structured reply — no harmony text leaked to the visible stream and no regression in normal (non-harmony) operation.

  • What was not tested: I was unable to deterministically force a fresh harmony emission during this session's live dispatches — gpt-oss-120b on LM Studio at 102K loaded context emitted structured tool_calls correctly for the prompts I ran, so the buffer's harmony branch was not exercised on a fresh dispatch. The earlier live emissions captured this morning are still the cleanest "real harmony" evidence I have; the pnpm gateway:dev dispatch above proves the new wrapping does not regress normal operation. Per the lab notebook the leak is deterministic at 64K loaded context but I did not reload the model at that size to avoid disrupting other workflows on the same LM Studio instance.

Notes vs #78339

Same root cause and same target. This PR additionally addresses the two pieces of ClawSweeper's two-piece fix that #78339 leaves out (LM Studio prefix buffer, strip-path short-circuit), and adds the user-facing CHANGELOG entry.

Update history

  • 9753f550 — non-substantive rebase onto origin/main at fc1e2c50 (fix(reply): preserve private group replies for text turns). That upstream commit fixes 3 deterministic failures in src/auto-reply/reply/dispatch-from-config.test.ts (expected 'automatic' to be 'message_tool_only') that were red on main itself when this PR was first opened against 9bcb56b4. No changes to this PR's source code, tests, CHANGELOG, or proof — git diff fc95f3fd 9753f550 is just the CHANGELOG conflict resolution (re-anchoring my entry below the four entries that landed upstream while the PR was being prepared).

Fixes #78326.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/lmstudio/src/stream.test.ts (modified, +141/-1)
  • extensions/lmstudio/src/stream.ts (modified, +10/-5)
  • src/plugin-sdk/tool-payload.test.ts (modified, +244/-1)
  • src/plugin-sdk/tool-payload.ts (modified, +107/-6)

Code Example

Evidence 1 — gpt-oss-120b on LM Studio CAN emit proper tool_calls when
given a clean OpenAI tools schema (so the model + LM Studio are healthy
in the small-prompt case):

    $ curl -sN http://localhost:1234/v1/chat/completions \
        -H "Content-Type: application/json" -d '{
          "model": "gpt-oss-120b",
          "messages": [{"role":"user","content":"List /tmp using the exec tool."}],
          "tools": [{
            "type":"function",
            "function":{
              "name":"exec",
              "parameters":{
                "type":"object",
                "properties":{"command":{"type":"string"}},
                "required":["command"]
              }
            }
          }],
          "stream": false
        }' | jq '.choices[0].message'

    {
      "content": "",
      "tool_calls": [
        { "type": "function", "id": "...",
          "function": { "name": "exec", "arguments": "{\"command\":\"ls -la /tmp\"}" } }
      ]
    }

Evidence 2 — verbatim assistant text observed in
~/.openclaw/agents/<name>/sessions/*.jsonl after a heavy dispatch
(redacted to a generic path):

    commentary to=read code {"path":"/path/to/file","line_start":1,"line_end":400}

The structure also occasionally arrives with the full Harmony delimiters
preserved, e.g.

    <|channel|>commentary to=read code<|message|>{"path":"...", ...}

…and across the three Harmony channels gpt-oss models use (commentary,
analysis, final).

Evidence 3 — parser-level repro (deterministic, no inference server
required), copied from the Steps to reproduce section above:

    $ pnpm exec node --input-type=module -e "
        const { parseStandalonePlainTextToolCallBlocks } = await import('./src/plugin-sdk/tool-payload.ts');
        console.log(parseStandalonePlainTextToolCallBlocks(
          'commentary to=read code {\"path\":\"/path/to/file\",\"line_start\":1,\"line_end\":400}'
        ));
      "
    null

Evidence 4 — verification of the proposed fix locally. After patching
parsePlainTextToolCallBlockAt with a parallel parseHarmonyOpening branch
(diff in companion PR if accepted), the same dispatch that previously
produced 0 tool calls now produces 16 successful tool invocations and
completes its task. 22 vitest cases (covering the existing bracket
behavior unchanged + the new harmony shapes + negative cases) pass under
`pnpm exec vitest run --config test/vitest/vitest.unit-fast.config.ts plugin-sdk/tool-payload`.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On LM Studio with gpt-oss-120b, agent dispatches sometimes terminate after the model's first turn with zero tool invocations because parseStandalonePlainTextToolCallBlocks (in src/plugin-sdk/tool-payload.ts) only recognizes bracket-style blocks and returns null for the model's native Harmony commentary-channel tool-call syntax, defeating the LM Studio extension's plain-text recovery path (wrapLmstudioPlainTextToolCalls in extensions/lmstudio/src/index.ts).

Steps to reproduce

  1. From the openclaw repo root, run: pnpm exec node --input-type=module -e " const { parseStandalonePlainTextToolCallBlocks } = await import('./src/plugin-sdk/tool-payload.ts'); const observed = 'commentary to=read code {"path":"/path/to/file","line_start":1,"line_end":400}'; console.log(parseStandalonePlainTextToolCallBlocks(observed)); " The input string is a verbatim fragment of an assistant text message produced by gpt-oss-120b on LM Studio when the chat-template wrapper passed the model's native tool-call output through as plain text.

  2. Observe: parser returns null.

  3. Expected: parser returns a structured PlainTextToolCallBlock[] with name "read" and arguments {path, line_start, line_end} populated, so the LM Studio extension's wrapLmstudioPlainTextToolCalls wrapper can promote the assistant message to a structured tool call.

For an end-to-end repro (requires LM Studio + gpt-oss-120b loaded):

  1. lms load gpt-oss-120b --context-length 102400
  2. In ~/.openclaw/openclaw.json: models.providers.lmstudio.api = "openai-completions"
  3. Configure any agent with a moderately heavy system prompt (e.g. bundled qa-style workspace, ~25K+ chars + ~15+ declared tools).
  4. Dispatch a tool-using request via openclaw agent --agent <name> --json --message "<request that requires a tool>".
  5. Observe in ~/.openclaw/agents/<name>/sessions/*.jsonl: assistant message content includes a text block of the form "commentary to=<tool> code {<json>}" followed by stopReason: "stop", zero toolCall blocks, run terminates without performing work.

Expected behavior

When the LM Studio extension's wrapLmstudioPlainTextToolCalls (extensions/lmstudio/src/index.ts) calls parseStandalonePlainTextToolCallBlocks on assistant text content that contains a Harmony-format tool-call block, the parser should return a structured PlainTextToolCallBlock[] with the tool name and JSON arguments populated. The recovery wrapper would then promote the message to stopReason "toolUse" with the tool call as content, the runtime would invoke the tool, and the agent loop would continue normally.

For the actual gpt-oss-120b output observed in the wild:

commentary to=read code {"path":"/path/to/file","line_start":1,"line_end":400}

…the parser should return:

[{ name: "read", arguments: { path: "/path/to/file", line_start: 1, line_end: 400 }, /* end, raw, start */ }]

This is the behavior the wrapLmstudioPlainTextToolCalls wrapper was designed for — it explicitly exists to recover plain-text tool calls back into structured form. The bug is purely that the parser's input-format coverage doesn't yet include the Harmony shape.

Actual behavior

parseStandalonePlainTextToolCallBlocks returns null for any harmony-format input. Its sub-parser parseOpening (src/plugin-sdk/tool-payload.ts ~line 91) short-circuits on text[start] !== "[", so the harmony shape (which starts with commentary/analysis/final or <|channel|>) is never considered.

Consequence chain (verified by walking the bundled JS during dispatches):

  1. wrapLmstudioPlainTextToolCalls receives null from the parser and therefore does not promote the message.
  2. The assistant message reaches the OpenClaw runtime as plain text content with stopReason: "stop".
  3. The agent loop terminates after the model's first turn — zero tool invocations, no work performed.
  4. CLI exit code is 0 — the user sees an apparently-successful dispatch that produced nothing.

Observable symptom in ~/.openclaw/agents/<name>/sessions/*.jsonl: an assistant message of the shape content: [ { type: "thinking", ... }, { type: "text", text: "commentary to=<tool> code {<json>}" } ] with no toolCall block, and a final qa-reply.json meta.agentMeta showing zero tool execution count for the run.

OpenClaw version

2026.5.4 (325df3e)

Operating system

macOS 26.4 (Darwin 25.4.0, arm64) — Apple M5 Max, 128 GB

Install method

npm global, into /opt/homebrew/lib/node_modules/openclaw (Node v25.8.1, npm 11.12.1)

Model

gpt-oss-120b (mlx-community 4-bit MXFP4 quantization, served by LM Studio)

Provider / routing chain

openclaw -> lmstudio (local, http://localhost:1234/v1)

Additional provider/model setup details

Relevant config keys (~/.openclaw/openclaw.json):

  • models.providers.lmstudio.api = "openai-completions"
  • models.providers.lmstudio.baseUrl = "http://localhost:1234/v1"
  • agents.defaults.contextTokens = 100000
  • agents.defaults.compaction = { mode: "safeguard" }
  • agents.defaults.contextPruning = { mode: "off" }

LM Studio loaded-model context: 102400 (slightly above OpenClaw's 100K threshold, so OpenClaw compaction fires before LM Studio's engine-level overflow handling).

LM Studio sampling defaults: Top K = 40, Top P = 0.95, Temperature = 0.8, Min P = off (LM Studio defaults; not aggressive nucleus filtering).

No proxies, no API keys (local-only), no auth profiles for the lmstudio provider.

The LM Studio extension's plugin manifest (extensions/lmstudio/openclaw.plugin.json) declares providerRequest.providers.lmstudio.openAICompletions.supportsStreamingUsage = true, which causes OpenClaw to send stream_options: { include_usage: true } to LM Studio. This fix landed between OpenClaw 2026.3.13 and 2026.5.4 and works correctly — token usage telemetry flows. The harmony-format parser gap is a separate issue from the streaming-usage receipt path.

Logs, screenshots, and evidence

Evidence 1 — gpt-oss-120b on LM Studio CAN emit proper tool_calls when
given a clean OpenAI tools schema (so the model + LM Studio are healthy
in the small-prompt case):

    $ curl -sN http://localhost:1234/v1/chat/completions \
        -H "Content-Type: application/json" -d '{
          "model": "gpt-oss-120b",
          "messages": [{"role":"user","content":"List /tmp using the exec tool."}],
          "tools": [{
            "type":"function",
            "function":{
              "name":"exec",
              "parameters":{
                "type":"object",
                "properties":{"command":{"type":"string"}},
                "required":["command"]
              }
            }
          }],
          "stream": false
        }' | jq '.choices[0].message'

    {
      "content": "",
      "tool_calls": [
        { "type": "function", "id": "...",
          "function": { "name": "exec", "arguments": "{\"command\":\"ls -la /tmp\"}" } }
      ]
    }

Evidence 2 — verbatim assistant text observed in
~/.openclaw/agents/<name>/sessions/*.jsonl after a heavy dispatch
(redacted to a generic path):

    commentary to=read code {"path":"/path/to/file","line_start":1,"line_end":400}

The structure also occasionally arrives with the full Harmony delimiters
preserved, e.g.

    <|channel|>commentary to=read code<|message|>{"path":"...", ...}

…and across the three Harmony channels gpt-oss models use (commentary,
analysis, final).

Evidence 3 — parser-level repro (deterministic, no inference server
required), copied from the Steps to reproduce section above:

    $ pnpm exec node --input-type=module -e "
        const { parseStandalonePlainTextToolCallBlocks } = await import('./src/plugin-sdk/tool-payload.ts');
        console.log(parseStandalonePlainTextToolCallBlocks(
          'commentary to=read code {\"path\":\"/path/to/file\",\"line_start\":1,\"line_end\":400}'
        ));
      "
    null

Evidence 4 — verification of the proposed fix locally. After patching
parsePlainTextToolCallBlockAt with a parallel parseHarmonyOpening branch
(diff in companion PR if accepted), the same dispatch that previously
produced 0 tool calls now produces 16 successful tool invocations and
completes its task. 22 vitest cases (covering the existing bracket
behavior unchanged + the new harmony shapes + negative cases) pass under
`pnpm exec vitest run --config test/vitest/vitest.unit-fast.config.ts plugin-sdk/tool-payload`.

Impact and severity

Affected: any OpenClaw user running an OpenAI Harmony-format-trained model (gpt-oss-120b verified; gpt-oss-20b and any future Harmony-trained release likely affected by the same code path) via LM Studio's openai-completions endpoint, when the agent context is non-trivial (heavy system prompt and/or many declared tools).

Severity: blocks workflow. The agent's dispatch returns exit 0 with no tool invocations and no observable error message; the user sees an apparently-successful run that produced nothing.

Frequency: 4/4 deterministic on the affected setup. Reproduces across loaded-context sizes (64K and 102K both verified). The same model on the same LM Studio instance correctly returns structured tool_calls when called via raw curl with a clean OpenAI request — so the trigger is something in OpenClaw's request shape (large system prompt, several tools, agent-runtime header injection) that occasionally causes LM Studio's chat-template wrapper to give up and pass the harmony commentary syntax through as text.

Consequence: dispatches return successfully but do no work. User-visible symptoms vary by surface — TUI shows the harmony commentary text as the agent's "reply"; channel-delivered messages would either render that text literally to the user or be routed to whatever path handles text-only-with-no-tool-call assistant turns.

Additional information

NOT_ENOUGH_INFO for a clean regression bisection. The parser gap was likely present in 2026.3.13 too, but I did not exercise this exact code path on that version — gpt-oss-120b on 2026.3.13 was failing for a different reason (the per-model compat.supportsUsageInStreaming default required manual opt-in, an issue resolved upstream in 2026.5.4 via the extensions/lmstudio plugin manifest), which masked any harmony-parser behavior. I cannot honestly call this a regression.

Workaround: switch the primary model to a non-Harmony-trained one (verified working: Qwen 3.6 35B-A3B Q8 on LM Studio with the same OpenClaw 2026.5.4 + openai-completions config). The harmony-parser code path is only exercised when the model emits harmony-shaped plain-text content, which is gpt-oss-specific.

The companion PR (if maintainers accept the proposed approach) is purely additive in src/plugin-sdk/tool-payload.ts: a new parseHarmonyOpening helper invoked only when the existing parseOpening returns null, and a small change to parsePlainTextToolCallBlockAt to skip the closing-tag requirement for harmony shapes (Harmony format has no required closing delimiter — the block ends at the JSON close, optionally with a trailing <|end|>/<|return|>/<|message|> consumed). Bracket-style behavior is unchanged.

This issue was investigated and the fix developed with Claude Code (Opus 4.7) in an autonomous session. The "Real behavior proof" runs above were executed live on my machine; wall-clock and tool-call counts come directly from harness output. I reviewed the diff and confirm I understand what the change does. Session log available on request.

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?
Loading…

FAQ

Expected behavior

When the LM Studio extension's wrapLmstudioPlainTextToolCalls (extensions/lmstudio/src/index.ts) calls parseStandalonePlainTextToolCallBlocks on assistant text content that contains a Harmony-format tool-call block, the parser should return a structured PlainTextToolCallBlock[] with the tool name and JSON arguments populated. The recovery wrapper would then promote the message to stopReason "toolUse" with the tool call as content, the runtime would invoke the tool, and the agent loop would continue normally.

For the actual gpt-oss-120b output observed in the wild:

commentary to=read code {"path":"/path/to/file","line_start":1,"line_end":400}

…the parser should return:

[{ name: "read", arguments: { path: "/path/to/file", line_start: 1, line_end: 400 }, /* end, raw, start */ }]

This is the behavior the wrapLmstudioPlainTextToolCalls wrapper was designed for — it explicitly exists to recover plain-text tool calls back into structured form. The bug is purely that the parser's input-format coverage doesn't yet include the Harmony shape.

#api#device allocation#model download#tokenizer error#prompt formatting

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: `parseStandalonePlainTextToolCallBlocks` doesn't recognize OpenAI Harmony-format tool calls (gpt-oss-120b on LM Studio) [2 pull requests, 1 comments, 2 participants]