approvalsRefusalsNotice
approvalsRefusalsNotice(
refusals):SlashCommandNotice|null
Defined in: packages/agent/src/modules/slashCommands.ts:986
[[EXT-107]] — the refusals in force, as their own notice: what is refused, which list holds
it, and the number that lifts it. null when nothing is refused, so /approvals says nothing
about refusals in the ordinary case.
This is the escape hatch, and it is the reason a refusal may be persisted at all. A session-only always reject cost minutes when it was a mistake; saved to a project file it costs whatever it takes the user to discover a file they were never told about. So this does not count refusals, it makes each one findable and undoable — which is why every line carries its origin and its number.
A second notice rather than more rows on the posture one, and the reason is the pane. The posture notice’s head is the answer the user asked for — which mode am I on — and it already fills the TUI pane the picker leaves: measured, ONE added row scrolls that head off the top. Two notices each keep their own heading, and the refusal list ends up nearest the prompt, which is where the thing the user is about to act on belongs.
The overflow is walkable rather than a dead end. The numbering is the runner’s, over a deterministic order (config, then saved, then session), so lifting the last shown entry brings the next one into the list. A cap that simply hid the rest would put refusals beyond reach of the control that exists to reach them.
Parameters
Section titled “Parameters”refusals
Section titled “refusals”readonly ApprovalRefusal[]
Returns
Section titled “Returns”SlashCommandNotice | null