[BUG] Agent re-submits a byte-identical rejected tool call 5x in a row while its prose claims the fix was applied

Summary

In a long session, the agent re-submitted a byte-identical rejected Bash command five consecutive times, each time after explicitly stating it had applied the fix that the rejection text named. The rejection came from a PreToolUse hook whose message contains the exact required form. This is not a probabilistic near-miss: the corrective signal is deterministic, machine-generated, and repeated verbatim on every attempt.

Environment

• Claude Code, VS Code extension
• Model: Opus 5, 1M context
• Date: 2026-09-11
• A local PreToolUse hook on Bash that rejects any command referencing a relative path unless the command begins with an explicit cd <absolute-dir> &&. The rejection text ends with:

``
Fix — say where it runs:
cd /work/sub && <command>
cd /work && <command>
``

Reproduction

1. Install a PreToolUse hook on Bash that exits non-zero with a message naming the required command prefix.
2. Ask the agent to run a series of shell commands that reference relative paths.
3. Observe the rejection, and the agent's next emitted command.

Observed

• The same command was emitted 5 times in a row without the required prefix. Between attempts the agent wrote, in visible text, that it had added the prefix — while the emitted command string had not changed.
• Across the session the same hook rejected roughly 30 calls for the same reason.
• The agent eventually switched strategy (absolute paths everywhere), which satisfied the hook. That workaround was reached only after the repeated failures, not from the rejection text.

Expected

After a rejection whose text names the required form, the next emitted command should either contain that form or take a different strategy. A deterministic, self-describing error should not be able to recur identically five times.

Why it matters

• Hook-based enforcement is the mechanism teams use to keep an agent inside a safety envelope. An agent that cannot incorporate hook feedback burns the turn budget on rejected calls; in a long session this becomes a large fraction of the work.
• The failure is silent to the user unless they read the tool log: the agent's prose claims the fix was applied, so the transcript reads as if progress is being made.

Notes

• The agent's own written claim ("this time the prefix is the literal first token") diverging from the emitted argument suggests the text and the tool-call arguments are not being generated from the same state.
• Related, previously filed: enforcement hooks self-neutralizing; compaction dropping governance rules; auto-memory outranking project instructions.