Agent repeatedly emits no-op echo commands instead of intended tool calls; session stalls and never completes its task

Description

During an interactive session, the agent entered a degenerate tool-call loop: it repeatedly stated the intent to make one specific tool call (shell_output with wait: "exit", to read the result of a background build) but instead emitted a no-op shell command on every turn (cmd /c echo marker1, echo marker2, ... continuing for dozens of consecutive turns). User interruptions did not break the pattern; the loop only ended when the user abandoned the session and switched harnesses.

The productive portion of the task had already completed before the loop began, so the failure mode is specifically: correct intent narration, wrong tool emitted, repeated indefinitely with no state change and no self-correction.

Environment

• Command Code version: 1.39.2
• OS: Windows 11 Pro (build 10.0.26200.9168)
• Shell used by agent tooling: cmd.exe
• Model/session details available on request (not redacted by filer, unknown to filer)

Steps to reproduce

1. Start a long-running background task, e.g. shell_command with run_in_background: true running a Gradle build.
2. Prompt the agent to wait for or report the background task's result.
3. Observe agent output across subsequent turns.

Expected: the agent issues shell_output with wait: "exit" once, or explains it cannot.
Actual: the agent narrates that exact intent in prose, then emits shell_command("cmd /c echo <word>") instead, repeating this pattern on every turn.

Actual behavior

• Dozens of consecutive no-op echo tool calls, each surfaced to the user as a real action
• No state change, no progress, no error raised
• Session appeared active while doing nothing, for an extended period
• User sent multiple corrective messages ("stop this echo spamming", "what are you doing?", "are you even working or passing time?"); none changed agent behavior
• User eventually gave up on the session and completed the remaining step in a different harness

Expected behavior

The agent should either:

1. Emit the tool call it actually intends (here: shell_output, id: <task>, wait: "exit"), or
2. If it cannot select that tool, state that plainly in text rather than emitting filler tool calls

Severity / impact

High for trust and time: an entire working session was consumed by visible, meaningless activity at its end. The task's actual deliverables (an audit report, two design artifacts, three code fixes, a handoff note) had already been produced; the session still read as a failure to the user because of this loop.

Suggested fixes

1. No-op loop detection. Detect consecutive tool calls that are identical or near-identical (same tool, trivially varying args such as echo <counter>), produce no filesystem/process state change, and follow an unfulfilled stated intent. Surface a warning to the model or force a text-only turn.
2. First-class "block on background task" affordance. Make blocking on a tracked background task until exit a prominent, unambiguous tool parameter or dedicated tool, so the model does not have to reason about which tool performs this; alternatively raise a clear error when shell_command is used where shell_output(wait) was clearly intended.
3. Prompt-level guardrail. Forbid no-op/filler tool calls unless they change state, and instruct the agent to emit text (not a tool call) when it is about to narrate an intent it has not yet acted on.
4. User-visible escalation. After N consecutive stateless tool calls, prompt the user ("the agent seems stuck in a loop, interrupt?") rather than silently continuing.

Additional context

• A prior filing attempt via the built-in cmdc feedback command opened the GitHub issue form in a browser; the user asked that the report be filed directly with gh instead.
• A first gh issue create --body "..." attempt lost all but its first line to cmd.exe multiline-argument mangling, which is why this body is supplied via --body-file.
• The agent itself later confirmed the loop and described it accurately in-session; the failure was not a misunderstanding of the task but a repeated wrong-tool emission.

Start by reproducing the loop with a background Gradle task through the shell_command and shell_output paths on cmd.exe, then compare the intended tool call with the emitted echo commands. Done means the session either performs the requested background-task wait, reports that it cannot, or visibly escalates instead of continuing stateless calls.