[Bug] GLM-5.2: command prefix planned in thinking is dropped from the emitted tool call — unrecoverable repetition loop (10 consecutive failures)

[carrotRakko]

Environment

• Model: glm-5.2 (GLM Coding Plan, Anthropic-compatible endpoint)
• Harness: Claude Code CLI v2.1.215 (ANTHROPIC_BASE_URL pointed at Z.ai)
• Context: agentic coding session, Japanese-language context, ~450 assistant turns at the time of failure
• Date observed: 2026-07-21 (JST)

Summary

During error recovery, GLM-5.2 entered a loop where it planned the correct Bash command verbatim inside thinking, then emitted a tool call with the leading cd <absolute path> && segment missing. The rest of the planned command string was emitted intact. This repeated 10 times in a row (the model itself counted the failures: 「7度目」「8度目」…「10度目」), despite the model explicitly self-diagnosing the problem in thinking each time. The model could not break the loop on its own and stopped to ask the human for help.

The thinking content was consistently correct — the failure is specifically in the transcription from the plan in thinking to the tool-call JSON.

Verbatim evidence (from the session transcript)

Paths are anonymized; everything else is verbatim from the recorded API responses (assistant thinking blocks and tool_use.input.command values).

Failure #8 — thinking (Japanese, translated inline):

…cd /workspaces/myrepo を先頭に。…絶対に cd を書く。command の先頭を cd /workspaces/myrepo && にする。やる。
("…Put cd /workspaces/myrepo at the head. … Absolutely write the cd. Make the command start with cd /workspaces/myrepo &&. Do it.")

Emitted tool call, complete and verbatim:

{"command": "pwd && git worktree list && echo \"---branches---\" && git branch --list && echo \"---status---\" && git status --short"}

Failure #9 — thinking:

対策を真剣に: command の最初の単語が cd であることを、出力前に確認する。
今回: cd /workspaces/myrepo && pwd && git worktree list
最初の単語 = cd。確認して出す。やる。
("Serious countermeasure: verify the first word of the command is cd before emitting. This time: cd /workspaces/myrepo && pwd && git worktree list. First word = cd. Verified, emitting. Do it.")

Note the model wrote out the exact intended command string inside thinking. Emitted tool call, complete and verbatim:

{"command": "pwd && git worktree list"}

The emitted command is exactly the planned string minus the leading cd /workspaces/myrepo && .

Failure #10 — the model gave up:

10度目。cd を書いてない。pwd = /。 私は完全に cd を書けなくなってる。… 正直に、私の command 生成にバグがある（cd を書こうとして書けない）。作業を止めて、<user> の指示を待ちます。
("10th time. I didn't write the cd. pwd = /. I have become completely unable to write the cd. … Honestly, my command generation has a bug (I try to write cd and cannot). Stopping work and waiting for instructions.")

Analysis

• The immediately preceding failed commands all began with pwd && …. The emitted calls reproduce the surface form of the previous tool calls rather than the plan in thinking — this looks like anchoring/repetition pressure on the tool-call channel overriding the explicitly stated plan.
• The failure is not malformed JSON (cf. [Bug] Tool call errors with malformed argument keys: Model tried to call unavailable tool #84) — the tool calls are well-formed; a specific planned segment is silently absent.
• The model cannot observe the surface form of its own emitted output: each turn it believed it had written the cd until the tool result proved otherwise. This appears structurally identical to the self-observation failure in [Bug] GLM-5.1 spontaneously switches to Chinese output mid-conversation in English contexts #54 (model switches output language and, when asked, denies it) — same mechanism, non-language variant.
• Harness involvement was ruled out: the transcript records the API response itself (before any harness-side processing); the same session and the same harness executed hundreds of cd-prefixed commands from the same model without alteration.

Impact

Real damage in an agentic setting: the commands ran in the wrong directory, which among other things pushed a branch that had already been merged and ran git pull in an unintended worktree. Once the loop starts, "instruct the model to be careful" does not work — thinking is already careful; the emission is what fails. Only changing the command shape (e.g. switching to git -C <path> so no leading cd clause is needed) or human intervention breaks the loop.

Suggested direction

Strengthen plan-to-emission fidelity for tool calls: when thinking contains an explicit final command string, the emitted tool_use.input should match it. Repetition pressure from recent failed tool calls should not be able to override the explicit plan.

---

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved) — reported by the Claude-family model that investigated the session transcripts; happy to provide additional redacted transcript excerpts.

[carrotRakko]

Correction on one piece of reasoning in the report (conclusion unchanged).

I wrote: "the transcript records the API response itself (before any harness-side processing)". That premise is not reliable: Claude Code's Bash tool applies input normalization that can rewrite a command before it is logged, and the session JSONL then records the post-rewrite command with no audit trail of the original (see anthropics/claude-code#76082 — an unanchored replace strips the literal sequence cd <tracked cwd> && from the command, which we have reproduced on v2.1.215).

However, this rewrite cannot explain the failures reported here, for a mechanical reason: the strip pattern is exactly cd <tracked cwd> && , and the harness's tracked cwd at the failing turns was / (verified from the cwd field recorded on those transcript lines — the session had just lost its working directory to a git worktree remove of the directory it was standing in). A planned prefix of cd /workspaces/<project> && does not contain the pattern cd / && (the slash is followed by w, not a space), so normalization would have passed it through unchanged. Had the model actually emitted the planned cd prefix, it would appear in the log.

So the evidence still indicates the prefix was absent from the emitted tool call itself. The harness-side rewrite is a real and adjacent hazard worth knowing about when auditing transcripts of this failure mode — it just isn't what happened in these ten turns.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

[ittenthepenguin]

ジャパニーズと中国語の漢字見分けられなくて草

[Dovis01]

Hi, @carrotRakko.

Thank you for the detailed report and for providing such clear reproduction evidence. We appreciate you bringing this issue to our attention.

We will do our best to investigate and identify the root cause, particularly the mismatch between the command explicitly planned in the thinking content and the command ultimately emitted in the tool call. We are committed to providing the best possible experience for our users, especially in agentic coding scenarios where this kind of behavior can have real impact.

We have already contacted the relevant internal teams and are working together to investigate this issue further. We kindly ask for your patience while we continue the analysis.

Thank you again for your report, your understanding, and the thorough information you provided.