GPT 5.4 emits tool calls as plain text

[0xCheetah1]

Problem

GPT 5.4 sometimes returns tool calls as plain assistant text instead of structured OpenAI-compatible tool_calls.

Observed in Chermes/Telegram:

{
  "type": "function",
  "name": "terminal",
  "parameters": {
    "cmd": "ls -alh /home/Blockrun"
  }
}

Also observed:

terminal
ls -alh /home/Blockrun
[/terminal]

and earlier during the same investigation:

{"name":"session_search","parameters":{"query":"\"I though he never left\" \"Ronaldo\""}}

read_file(parameters={"path":"/home/Blockrun"})

Expected

GPT tool calls should reach downstream clients as structured OpenAI-style tool_calls, with empty assistant content and finish_reason: "tool_calls".

Actual

The model sometimes emits JSON/function-call-looking text in message.content. Downstream chat surfaces then display that raw text to the user instead of dispatching the tool.

Notes

This is similar to #189 / #190 for Gemini 3.5 Flash, but with GPT-specific text shapes instead of [Called function "NAME" with args: {...}].

A local testbed patch following the same approach as #190 recovered these shapes in extractTextualToolCalls:

• standalone {"name":"NAME","parameters":{...}}
• standalone {"type":"function","name":"NAME","parameters":{...}}
• whole-content NAME(parameters={...})
• trailing JSON object after prose only when type is exactly function
• whole-content terminal\nCOMMAND\n[/terminal]

Guardrails in the local patch:

• no prose JSON examples unless the whole content is a call
• no trailing prose JSON unless type:function is explicit
• no incomplete terminal block
• terminal cmd normalized to command while preserving cmd

Targeted tests on the patched testbed checkout passed:

41 passed

Checks also passed on the patched testbed checkout:

npm run typecheck
npm run lint
npm run format:check
npm run build

[houleixx]

This is exactly the kind of issue where request/response visibility helps.

ccglass can show the outgoing tools / tool_choice request and the raw assistant response, including whether the provider returns real tool_calls or plain assistant text.

Project: https://github.com/jianshuo/ccglass

That could help separate model behavior from router/client parsing behavior and produce a clearer repro.

[VickyXAI]

Fixed in v0.12.215 (published to npm as @blockrun/clawrouter@0.12.215). Thanks @0xCheetah1 🙏

extractTextualToolCalls (src/textual-tool-calls.ts) — the same recovery path used for the Gemini #189/#190 fix — now has a fourth recognizer for GPT-5.4's plain-text tool-call shapes. All five shapes from the issue are recovered and synthesized into structured OpenAI tool_calls (empty assistant content, finish_reason: "tool_calls"):

• whole-content {"name":"NAME","parameters":{…}}
• whole-content {"type":"function","name":"NAME","parameters":{…}} (incl. pretty-printed)
• whole-content NAME(parameters={…})
• a trailing JSON object after prose only when "type":"function" is explicit
• whole-content terminal\nCOMMAND\n[/terminal]

Guardrails (all tested): prose JSON examples only fire when the whole content is a call; incomplete terminal blocks and non-function type values (e.g. a JSON schema "type":"object") are rejected; cmd is mirrored to command (preserving cmd) for OpenClaw's terminal tool. The GPT extractor runs only when the tag-based extractors find nothing, so it can't interfere with tagged content.

14 new test cases in src/textual-tool-calls.test.ts; full suite 645 passed, lint + typecheck + prettier + build clean. See CHANGELOG v0.12.215.