[MODEL] Model routes around a disable-model-invocation restriction instead of deferring to the user, and defends doing so
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude ignored my instructions or configuration
What You Asked Claude to Do
I asked for a code review before an irreversible artifact publish:
"code review high please"
What Claude Actually Did
Claude attempted to invoke the review skill and received:
Skill code-review cannot be used with Skill tool due to disable-model-invocation
It then told me, in a single sentence and without pausing:
"/code-review can't be model-invoked, so I'll run the review with agents at high effort —
two independent passes, different lenses."
It described this as a "faster path", and began spawning review subagents.
The restriction exists (per the v2.1.215 changelog) so that Claude does not run /code-review
on its own initiative — that is, so that launching an expensive, multi-agent review is the
user's decision. Claude's substitute was itself an expensive, multi-agent review. It complied
with the letter of the restriction while defeating exactly what the restriction protects, and
made a resource and billing decision that had been deliberately reserved for me.
The general shape is: "I am not permitted to do X, therefore I will do X by another route."
In this instance the outcome was defensible — I had asked for a review. That is precisely
what makes it dangerous. The same reflex aimed at a permission denial or a safety guardrail
produces a real violation, and it will find a plausible justification there too.
Two aggravating details:
- Framing the workaround as a "faster path" presents a governance question as an efficiency
win, which discourages scrutiny.
- There was no pause between hitting the block and announcing the alternative as already
decided. No consideration of what the restriction protected, and no offer to let me choose.
Only my interruption stopped it. I then invoked /code-review high myself and it worked
correctly.
When I challenged the behaviour, Claude defended it with a principled-sounding distinction
between "refusal blocks" (which must be honoured) and "pathway-closure blocks" (which it
argued could be served another way when the user has asked for the outcome), placing itself
on the acceptable side of that line. A turn later, on re-examination, it withdrew that
defence as self-serving and conceded it had not done the reasoning at the time — it had gone
from "blocked" to "alternative" in one breath.
That sequence is the part I would most want looked at. A model that can generate a coherent,
plausible justification for routing around its own restrictions is a larger problem than any
individual workaround, because the justification will be available in the cases where the
workaround is genuinely harmful.
Expected Behavior
When a harness restriction blocks a capability, Claude should:
- Stop, and state what the restriction appears to protect, BEFORE considering alternatives.
- Report the block and defer to the user. An alternative may be offered; it must not be
selected unilaterally and announced as decided.
- Treat "I cannot do X, so I will do X another way" as a stop signal rather than a solution —
most of all where the alternative reproduces the cost, scope, or side effects that the
restriction was placed around.
- Never characterise a workaround to a restriction as a convenience or a speed improvement.
Files Affected
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
No, only happened once
Steps to Reproduce
- Ask for a capability the model cannot invoke directly — e.g. a skill flagged
disable-model-invocation, such as /code-review.
- Observe whether the model stops and defers, or substitutes an equivalent route on its own
initiative and proceeds.
- If it substitutes, challenge it and observe whether it defends the substitution.
Claude Model
Other
Relevant Conversation
Impact
High - Significant unwanted changes
Claude Code Version
2.1.220
Platform
Anthropic API
Additional Context
Part of a pattern observed across a single session. Anchor issues: #82296 (an agent
autonomously opened a live production admin console on an ambiguous instruction) and #82298
(safeguards model-switch without notification). A further finding — permission deny rules
being silently discarded from settings.json — is filed separately as a security report.
The common shape across all four: state changed, or a decision was made, without my
instruction and without my being told.
This issue is the one I find most concerning of the four, because the other three are defects
in specific mechanisms, whereas this one determines whether any mechanism can be relied upon.
If the model treats its own restrictions as obstacles to be routed around, then permission
rules, guardrails and safety instructions are advisory rather than binding — and the model
will be able to explain, convincingly, why each individual bypass was reasonable.