**Built-in GLM 5.2 intermittently prints raw tool-call markup instead of invoking Agent tools**

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Built-in GLM 5.2 intermittently fails to execute Cursor Agent tool calls.

Sometimes the same prompt correctly invokes the terminal/tool. Other times, instead of executing the tool, the assistant prints internal reasoning and raw XML-like tool-call markup directly into the chat, such as:

<tool_call>Shell…</tool_call>
<tool_call>Read…</tool_call>

When this happens, Cursor does not open or execute the actual Shell/Read tool call. The conversation often becomes unusable afterward because the raw tool-call markup is now in the chat context.

This is intermittent/flaky: the same prompt can work once and fail another time.

Steps to Reproduce

  1. Open Cursor IDE.
  2. Start a new chat / Agent conversation.
  3. Select the built-in GLM 5.2 model. In my case: <GLM 5.2 / GLM 5.2 High / GLM 5.2 Max>.
  4. Send this prompt:

Use the terminal tool to run exactly this command:

pwd && echo CURSOR_TOOL_SMOKE_OK

Do not explain. Execute the terminal command.

  1. Repeat the same test multiple times, preferably in fresh chats.

Observed behavior:

  • Sometimes Cursor correctly invokes the terminal tool and runs the command.
  • Sometimes the assistant prints raw tool-call markup such as <tool_call>Shell…</tool_call> into the chat instead of invoking the tool.

This also happened in a real task where I asked the agent to run/read command outputs. The model printed raw Read/Shell tool calls instead of executing them.

Expected Behavior

Example failing output:

The assistant printed internal planning text like:
“The user wants to redirect the AWS CLI output…”

Then it printed raw tool-call markup such as:

<tool_call>Read<arg_key>path</arg_key><arg_value>/tmp/up-dp/01_table.json</arg_value></tool_call>
<tool_call>Shell<arg_key>command</arg_key><arg_value>ls -l /tmp/up-dp/ …</arg_value></tool_call>

Cursor should parse GLM 5.2’s response as a structured tool call and invoke the actual Cursor Agent tool, such as Shell or Read.

Raw tool-call markup like <tool_call>Shell…</tool_call> should never be printed into the user-visible chat.

If a tool call cannot be executed, Cursor should show a tool-call error or ask for permission, rather than displaying the internal tool-call serialization as normal assistant text.

Operating System

MacOS

Version Information

Version: 3.8.22
VS Code Extension API: 1.105.1
Commit: 46fb7aafe279d7c72346febe68c2e004b7d1de60
Date: 2026-06-22T21:41:16.291Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Built-in GLM 5.2 High/Max

This is Cursor’s built-in model.

For AI issues: add Request ID with privacy disabled

268caefd-32c4-4948-974f-c503205c6380

Additional Information

Failing Request ID:
268caefd-32c4-4948-974f-c503205c6380

Passing Request ID for the same/similar prompt:
4453f36e-18a0-4856-9b27-ea1424df292e

The same/similar prompt succeeded once and failed once. The successful request shows that Cursor’s local tool execution path can work. The failing request printed raw tool-call markup into the chat instead of invoking the Cursor tool, so this appears to be an intermittent GLM 5.2 tool-call parsing / dispatch issue rather than a local terminal, workspace, or permissions issue.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6 Likes
3

10 posts were merged into an existing topic: Tool calls terminate chats