xAI Grok 4.5 generating useless bash true tool calls

[berenddeboer]

Description

Seeing this:

User chose 1 but didn't pick A or B. They said "1" only. I should clarify A vs B, or assume they want 1 and ask about A/B.
$ true
(no output)
Thought: 3ms
Just ask the follow-up.
$ true
(no output)
Thought: 4ms
I need to just output text without tool calls.
$ true
(no output)
Thought: 267ms
There seems to be a bug where I keep generating bash. Let me try a different approach - just pure text response without any tool calls at all.

Screenshot:

Plugins

No response

OpenCode version

1.18.3

Steps to reproduce

I think it only happens with xAI Grok.

Screenshot and/or share link

No response

Operating System

Omarchy

Terminal

Alacritty/tmux

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• issue: grok coder runs and logs a lot of </xai:function_call> tool calls #2288: Similar behavior where Grok generates excessive/repetitive tool calls in a loop (now closed, but the symptom is closely related)

[rekram1-node]

can u share a session?

[berenddeboer]

can u share a session?

See here: https://opncd.ai/share/TVclnOCU

[berenddeboer]

@rekram1-node another one, just now, much shorter: https://opncd.ai/share/Y6IxNeMe

[berenddeboer]

@rekram1-node haven't seen this for a while now.

[dakotad74]

Also hitting this with Kimi k3 (kimi-for-coding provider, "max" variant) on opencode 1.18.23 — 132 degenerate bash {"command": "true"} calls across 6 sessions over 2 days (2026-08-26/27).

Same signature as reported here:

• The model's reasoning is fully aware of the misfire but can't break it: "OK something is wrong with my tool invocation — I keep sending bash true. Let me consciously invoke the skill tool with name 'brainstorming'" → emits bash true again.
• Selective failure: it collapses when trying to invoke non-bash tools (skill, MCP engram_mem_save, task / subagents). Plain bash and question calls work fine in the same sessions.
• Context at failure points: 68k–148k tokens.
• doom_loop never prompted in these sessions. The detector (packages/opencode/src/session/processor.ts:353) only inspects parts of the current assistant message, and the model emits exactly one true per message — so this is exactly the case PR fix(processor): detect doom loops across messages instead of within current message #32089 fixes. Also affected by the second bug described there: reasoning parts interleaved between tool calls make slice(-3).every(...) pass silently.

I have full message/part dumps from opencode.db (session IDs, token counts, reasoning traces) if useful for repro.

Workaround that works for us: ESC to abort, then /compact or a fresh session — typing "continue" re-seeds the loop.

[berenddeboer]

I haven't seen this in ages anymore btw.