GLM 5.3: Tool calls terminate chats

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

With GLM 5.3, any time the model makes several tool calls in parallel (in one step), the arguments never reach the tools. Every call in the batch fails with an empty-argument error, for example:

{“type”:“tool_call”,“subtype”:“completed”, … “readToolCall”:{“result”:{“error”:{“errorMessage”:“Invalid arguments:\npath: Required”}}}}
{“type”:“tool_call”,“subtype”:“completed”, … “globToolCall”:{“result”:{“error”:{“error”:“Invalid arguments:\nglob_pattern: Required”}}}}

The model then stops and says its tool calls are “losing their parameters”. It asks the user to paste the file contents or restart the session.

It happens with both glm-5p3 and glm-5p3[reasoning=high]. Sequential tool calls (one per step) work fine. On a small folder GLM tends to read files one at a time, so it often works. On a larger workspace (about 360 files) it batches its reads, and the run fails: 3 of 4 runs did. Kimi K3 on the same tasks and workspace had no failures.

Steps to Reproduce

Create a folder with six small text files, rec1.txt to rec6.txt, each with a line such as Amount: 1111.25.
Run:
cursor-agent -p --mode ask --trust --model “glm-5p3[reasoning=high]” --output-format stream-json --workspace “Read all six rec*.txt files in parallel in a single step and report the total of the Amount lines.”
Look at the tool_call events: every call fails with Invalid arguments: path: Required (10 of 10 failed in my test), and no total is returned.
Run the same task with this added to the front of the prompt: “Make exactly ONE tool call per step; never call tools in parallel.” All reads succeed and the total is correct (11 of 11 calls succeeded on the larger workspace).

Expected Behavior

GLM 5.3’s parallel tool calls should arrive with their arguments, as they do for Kimi K3 and other models in the same CLI. Failing that, the CLI should run them one at a time. Tool calls should work and the run should continue normally.

Operating System

Windows 10/11

Version Information

Cursor Agent CLI 2026.10.01-14929f9 (build 2026.10.01-e373342 is also installed and lists the same models)
Invoked headless via cursor-agent.cmd -p --mode ask --trust --output-format text|stream-json

For AI issues: which model did you use?

GLM 5.3 (glm-5p3, with and without [reasoning=high])

Additional Information

cursor-agent models / --list-models shows only glm-5.2-high and glm-5.2-max.
–model glm-5.3 and --model glm-5.3-high are rejected with “Cannot use this model”.
The slug that works headless is glm-5p3. I only found it in ~/.cursor/cli-config.json after picking “GLM 5.3 High” in the interactive CLI.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @Zach_Huston, thanks for the detailed report and the repro steps!

This is a known issue we’re already tracking. With GLM 5.3, some tool calls are reaching the agent with their arguments missing, which is why Read, Glob, and Shell fail with “: Required”. It isn’t caused by your workspace, CLI version, or OS.

It isn’t limited to parallel calls. It also shows up on single calls, but batching makes it much easier to hit, which matches what you saw on the larger workspace.

In the meantime, GLM 5.3 Flash is working normally again, and GLM 5.2 or any non-GLM model also avoids it. Updates are on the main thread: GLM 5.3 agent tool calls intermittently arrive with empty arguments — pattern: Required / command: Required

On the model name: glm-5p3 (or glm-5p3-high) is the correct ID for headless use. The argument issue still applies to that ID.