GLM 5.2: Tool calls terminate chats

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am experiencing an issue now in which every time a tool call is made, something like this will be displayed in the chat window:

<tool_call>Grep<arg_key>pattern</arg_key><arg_value>useSharedValue</arg_value><arg_key>path</arg_key>…

And then the chat just terminates.

Steps to Reproduce

Make a prompt in which the agent does a tool call such as Read or Grep

Expected Behavior

Tools calls should function properly and chats should proceed as per normal

Operating System

MacOS

Version Information

Version: 3.10.20 (Universal)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: IDE
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?

GLM 5.2 MAX

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

I have the same issue in the same environment: intel Mac + glm 5.2 max. Happened just now.

6

Have switched to GPT-5.5 to see if this issue still happens and apparently not. Perhaps it’s an issue localized to GLM 5.2.

7

Tried GLM 5.2 again and the issue seems to have resolved already.

9

I am still seeing the issue on GLM 5.2, tried restarting cursor but didn’t help. Issue seems to be localized to GLM 5.2 only

11

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every time I use GLM 5.2 model and a tool call is made, I see it being displayed in the chat window:

<tool_call>Grep<arg_key>-n</arg_key><arg_value>true</arg_value><arg_key>output_mode</arg_key><arg_value>content</arg_value><arg_key>path</arg_key><arg_value> ...

and the chat simply terminates.

Steps to Reproduce

Any prompt that requires a tool call like Read or Grep, with GLM 5.2 model selected.

Expected Behavior

Tools calls should work properly and full response/actions concluded.

Operating System

MacOS

Version Information

Version: 3.10.20 (Universal)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: Agent Window
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?

GLM 5.2 High

Additional Information

Very annoying, so far only happens with GLM 5.2 model, the other seem to be working fine

Does this stop you from using Cursor

No - Cursor works, but with this issue

13

Yep, issue is unfortunately back for me as well.

14

GLM 5.2, same problem on Windows.

15

GLM 5.2 starts acting stupid in Cursor at the same time Grok 4.5 drops. I get you were acquired but come on.

Put resources where they matter cause I’m pretty sure you all aren’t paying GLM in the sense that you do with other models. You very likely are running it in one of these new data centers you now have access to. No one wants Grok shoved down their throat especially by nerfing one of the best open sourced models that currently exists. Hooking up my OpenRouter key and using GLM that way since that at least works.

Edit: It’s extremely clear you guys have killed tool calling for GLM, this isn’t a provider issue when you are literally the providers. Fix this.

17

Same issue here. GLM-5.2

19

This seems to only be affecting GLM 5.2, which is what makes it so odd. One of the strongest open-source coding models suddenly can’t tool call properly in Cursor, right as Grok 4.5 gets introduced.

Maybe it’s just a regression, but from the outside it definitely feels like manual product routing,

21

I don’t even have Grok in my available models :man_shrugging:

22

yep, getting the exact same feeling

24

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

27

Hi @XuanmingLi Thanks very much for reporting this, I am taking a look and flagging this internally. Thank you for including the request IDs, however, I notice you have privacy mode on so we can’t see any details about the request. If you don’t mind, can you toggle privacy mode off and re-create the scenarios where it failed and worked and send us the new request IDs?

If you don’t have time, don’t worry, but if you are able to, this would be a big help.

To disable Privacy Mode:

  1. Open Cursor Settings with Cmd+Shift+J on macOS or Ctrl+Shift+J on Windows/Linux.
  2. Go to General.
  3. Turn Privacy Mode off / switch to Share Data.

To get the Request ID:

  1. Open the relevant conversation in the Chat sidebar.
  2. Click the ... menu.
  3. Select Copy Request ID.
28

Hi all, just weighing in here to add some details. This has to do with how GLM 5.2’s tool calls are being parsed, where they sometimes get printed into the chat as raw text instead of actually running. This is a gap and it is not intentional. I ask you all to kindly please refrain from conspiracy theories here please and thank you!

31

We are aware of the issue and we have a bug report raised to fix it, we’ll keep you updated on its status

32

@XuanmingLi No need to reproduce we have an internal reproduction of the issue and we have a bug report filed, I’ll let you know any updates in terms of its status.

35

following, have been experiencing this issue since morning.. :eyes:

36

We’ll keep you updated! Realistically it may take some time to be fixed