Refusing can say why, and the why is an instruction

"Don't" told the model it was refused and nothing else, so it did the one
sensible thing left and asked what you would rather -- a whole round spent on
something you knew when you pressed the button. "Give reason" opens a box beside
it, and what you write goes back with the refusal.

The reason changes what the model is *told*, not only what it reads, and that is
the whole of the feature. `_not_allowed` branches: given nothing to go on, "say
what you were going to do and ask what they would prefer" is right; given a
reason it is exactly wrong, because the answer is already on the screen above and
the model spends a round asking for it again. So it is pointed at the reason and
told to carry on from it. The "do not look for a way round" half is kept either
way -- that half is about the refusal and holds regardless.

A card-level field rather than `text.<key>`. One card covers everything in the
round for the reason the primitive exists, so one reason answers the round; and
on an approval card `text.<key>` already means a corrected command, which is a
different thing arriving in the same shape. Read only on a refusal, so a reason
typed and then abandoned by pressing Allow cannot travel with a permission.
Bounded where the Reply is built, so nothing downstream thinks about length, and
put on the tool event as well as in the result -- a transcript saying a step was
refused without saying why is one you had to have been watching to understand.

It is also the one thing in a tool result that is genuinely not untrusted: the
reader's own words, stated as theirs, needing no fence.

Both halves of the control are in the DOM with one hidden and the textarea
disabled while hidden, which is the rule the edit box beside it already states:
a field created by a click submits nothing when the click handler fails, and an
empty `reason` arriving would have to be told from one somebody cleared.

The version bump is not incidental. chat.css changed and the service worker
caches it under a name keyed on the version, so without it the first reload
serves the old stylesheet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jaroslav Beneš
2026-08-05 12:44:54 +02:00
parent ab4ffa2e5a
commit f4bf1bf670
10 changed files with 371 additions and 17 deletions
+23
View File
@@ -1915,6 +1915,29 @@ up with no way past it. The instance's list still governs the model, because
`decide` reads it before the allow list, so a pattern "always allow" remembered
from an edit cannot widen past it.
**"Don't" can carry a reason, and the reason changes what the model is told, not
just what it reads.** A bare refusal says only that it was refused, so the model
does the one sensible thing left and asks what you would rather — a whole round
spent on something you knew when you pressed the button. `Reply.reason` is how
that round is skipped, and `_not_allowed` branches on it: with nothing to go on,
"say what you were going to do and ask what they would prefer"; with a reason,
that instruction is *wrong*, because the answer is already on the screen above,
so the model is pointed at it and told to carry on from it. The "do not look for
a way round" half is kept either way — that half is about the refusal, which
holds regardless.
It is a **card-level** field, not `text.<key>`. One card covers everything in the
round for the reason this whole primitive does, so one reason answers the round —
and on an approval card `text.<key>` already means a *corrected command*, which is
a different thing arriving in the same shape. It is read only on a refusal, so a
reason typed and then abandoned by pressing Allow cannot travel with a permission.
Bounded at `MAX_REASON_CHARS` where the `Reply` is built, so nothing downstream
has to think about length, and it goes on the tool event as well as into the
result — a transcript that says a step was refused without saying why is one you
have to have been watching to understand. It is the one thing in a tool result
that is genuinely *not* untrusted: it is the reader's own words, so it is stated
as theirs and needs no fence.
**A control wired to a method its route does not serve fails silently.** The
agent-mode select posted with `hx-post` against a route that only answers
`PATCH`, so every change returned 405 and the mode never moved — for the whole