update_custom_attribute with required: true is refused by the Claude Code auto-mode
classifier, so an agent cannot finish a governance setup it is otherwise authorized to do.
What happens
mcp__..._massdriver__update_custom_attribute { id: "<uuid>", required: true }
→ Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier.
The operator had to open the UI and flip the flag by hand. Every other step in the same
flow — create_custom_attribute, create_group, create_policy — went through.
create_policy is also refused intermittently. The same call, retried unchanged
seconds later, succeeded. Two of eleven policy creations were refused on first attempt.
Why this should be allowed
required: true is a schema-tightening change. It makes an attribute mandatory at its
scope going forward. It does not delete data, does not touch infrastructure, and is
reversible with the same mutation. It is strictly more restrictive than the state it
replaces, which is the opposite of the risk the classifier is presumably screening for.
Blocking it is also self-defeating for the guardrail story: required: true is what
forces every new project to declare its owner and every environment to declare its tier.
An agent that can create attributes and write policies against them, but cannot mark them
required, produces a governance model with a hole in it and no signal that the hole exists.
Suggested fix
Set MCP tool annotations on the server so the classifier can size these calls correctly:
update_custom_attribute — destructiveHint: false, idempotentHint: truecreate_custom_attribute, create_group, create_policy — destructiveHint: false
If the intermittent create_policy refusals persist after annotation, they are worth
chasing separately — nondeterminism on an unchanged call is hard to write runbooks around.
Repro
create_custom_attribute { key: "tier", scope: "ENVIRONMENT", values: ["dev","staging","production"], required: false }- Tag existing environments with
mass environment update <env> -a tier=dev
update_custom_attribute { id: "<id from step 1>", required: true } → refused
Create-then-tag-then-require is the only safe ordering, since marking an attribute required
while resources at that scope lack it is the case worth avoiding. So this is the normal path,
not an edge case.
update_custom_attributewithrequired: trueis refused by the Claude Code auto-modeclassifier, so an agent cannot finish a governance setup it is otherwise authorized to do.
What happens
The operator had to open the UI and flip the flag by hand. Every other step in the same
flow —
create_custom_attribute,create_group,create_policy— went through.create_policyis also refused intermittently. The same call, retried unchangedseconds later, succeeded. Two of eleven policy creations were refused on first attempt.
Why this should be allowed
required: trueis a schema-tightening change. It makes an attribute mandatory at itsscope going forward. It does not delete data, does not touch infrastructure, and is
reversible with the same mutation. It is strictly more restrictive than the state it
replaces, which is the opposite of the risk the classifier is presumably screening for.
Blocking it is also self-defeating for the guardrail story:
required: trueis whatforces every new project to declare its owner and every environment to declare its tier.
An agent that can create attributes and write policies against them, but cannot mark them
required, produces a governance model with a hole in it and no signal that the hole exists.
Suggested fix
Set MCP tool annotations on the server so the classifier can size these calls correctly:
update_custom_attribute—destructiveHint: false,idempotentHint: truecreate_custom_attribute,create_group,create_policy—destructiveHint: falseIf the intermittent
create_policyrefusals persist after annotation, they are worthchasing separately — nondeterminism on an unchanged call is hard to write runbooks around.
Repro
create_custom_attribute { key: "tier", scope: "ENVIRONMENT", values: ["dev","staging","production"], required: false }mass environment update <env> -a tier=devupdate_custom_attribute { id: "<id from step 1>", required: true }→ refusedCreate-then-tag-then-require is the only safe ordering, since marking an attribute required
while resources at that scope lack it is the case worth avoiding. So this is the normal path,
not an edge case.