@gaunt-sloth/core 2.0.0-alpha.24 → 2.0.0-alpha.26

package/dist/core/GthAgentRunner.js

@@ -1,9 +1,18 @@
-import { getEffectiveDevToolsConfig, getShellJudgeSettings, isShellAllowlistEnabled, isShellAllowlistPersisted, isShellJudgeEnabled, } from '#src/config.js';
+import { DEFAULT_APPROVAL_RUNG, describeGrantedBuiltInTools, isRatedRung, resolveApprovals, resolveShellApprovalGate, SHELL_TOOL_NAME, TOOL_ANNOTATION_HINTS, } from '#src/config.js';
+import { StatusLevel, } from '#src/core/types.js';
 import { GthLangChainAgent } from '#src/core/GthLangChainAgent.js';
-import { AllowlistStore, PersistedAllowlist, matchesApproval, } from '#src/core/shell/allowlist.js';
+import { annotationWeakenings, ApprovalGrantStore, describeWeakenedGrant, PersistedApprovalGrants, shellGrantEntry, toolGrantEntry, trustWithdrawalWeakens, } from '#src/core/approvals/grants.js';
+import { renderApprovalEntryObject } from '#src/config/schema.js';
 import { classifyCommand } from '#src/core/shell/arity.js';
 import { normalizeCommand } from '#src/core/shell/normalize.js';
-import { judgeShellCommand, mapVerdictToAction, } from '#src/core/shell/judge.js';
+import { ApprovalStopError, AttackHaltError, NonInteractiveEscalationError, } from '#src/core/shell/approvalStop.js';
+import { applyDestructiveFloor, isRaterTimeout, mapAllowMatchedVerdictToAction, mapVerdictToAction, openWorldToolFloorReason, RATER_DEFAULT_TIMEOUT_MS, rateShellCommand, } from '#src/core/shell/rater.js';
+import { describeApprovalEntry, resolveApprovalRules, } from '#src/core/approvals/matcher.js';
+import { createEffectiveToolAnnotationSource, trustedAnnotationHints, } from '#src/core/approvals/annotations.js';
+import { approvalSubjectForToolName } from '#src/core/approvals/mcpSubjects.js';
+import { toolCallHosts } from '#src/core/approvals/toolHost.js';
+import { builtInToolAnnotations, mcpDeclaredAnnotationLookup, } from '#src/core/approvals/toolAnnotationSources.js';
+import { resolveRaterModel } from '#src/core/shell/raterModel.js';
 import { env } from '#src/utils/systemUtils.js';
 import { getGslothConfigWritePath } from '#src/utils/fileUtils.js';
 import { SHELL_ALLOWLIST_FILE } from '#src/constants.js';
@@ -18,6 +27,16 @@ import { setToolDisplayConfig } from '#src/core/toolDisplay.js';
  * kept; they are redacted (GS2-47) by the crash snapshot writer before anything reaches disk.
  */
 const CRASH_TRANSCRIPT_TAIL_MESSAGES = 8;
+/**
+ * A private copy of a rule entry, for handing to a display. `pattern` is the one field that can be
+ * an object (a `hint` pattern, §3.1), so it is copied too — a shallow spread alone would leave the
+ * displayed entry sharing the very object the matcher compares against.
+ */
+function copyApprovalEntry(entry) {
+    if (entry.type === 'shell' || typeof entry.pattern === 'string')
+        return { ...entry };
+    return { ...entry, pattern: { ...entry.pattern } };
+}
 /**
  * Agent simplifies interaction with LLM and reduces it to calling a few methods
  * {@link GthAgentRunner#init} and {@link GthAgentRunner#processMessages}.
@@ -46,30 +65,54 @@ export class GthAgentRunner {
      */
     lastRunStats = { tools: [] };
     /**
-     * EXT-12 — runtime, session-scoped auto-approve flag driven by the `/auto-approve` (a.k.a.
-     * `/yolo`) slash command. Because the shell tool stays gated (in `interruptOn`) in the
-     * interactive `code` mode, this flag is consulted at the TOP of {@link decideToolApproval}:
-     * when ON, a gated `run_shell_command` is auto-approved WITHOUT prompting for the rest of this
-     * runner's life. Never persisted, but INITIALIZED at {@link init} from the static
-     * `run_shell_command.yolo` config knob — so a config that pre-enables auto-approval still keeps the
-     * tool gated and therefore toggleable (`/auto-approve off` restores the per-command prompt).
+     * CFG-27 — the runtime, session-scoped approvals posture, seeded at {@link init} from
+     * {@link resolveApprovals} and thereafter switchable for the session by `/approvals <rung>`.
+     * The shell tool stays gated (in `interruptOn`) at EVERY rung, so this is consulted at the top
+     * of {@link decideToolApproval} and a config that pre-selects `bypass` remains switchable back
+     * mid-session. Never persisted.
+     *
      * It does NOT disable the hardline floor — catastrophic commands are still refused at exec time
-     * in `GthDevToolkit.executeCommand`.
+     * in `GthDevToolkit.executeCommand` under every rung.
+     */
+    sessionApprovals = {
+        rung: DEFAULT_APPROVAL_RUNG,
+        allow: [],
+        deny: [],
+        escalate: [],
+    };
+    /**
+     * CFG-26 — the model the AI rater rates with, when `approvals.rater.profile` names an identity
+     * profile. Resolved ONCE at {@link init} (never mid-turn) and handed to `rateShellCommand`;
+     * `undefined` means no profile is configured and the rater uses the session model.
+     */
+    raterModel;
+    /**
+     * EXT-66 — how many rating calls this session gave up on. Counted so the notice can say "3 times
+     * this session" rather than repeating an identical line, and so a silent drift toward
+     * escalate-everything has a number attached to it.
+     */
+    raterTimeouts = 0;
+    /**
+     * EXT-71 §3.1/§6 — what the escalation menu granted at run time, for the life of THIS runner
+     * instance: {@link ApprovalEntry} objects, never prefixes, and never anything from config (the
+     * declared lists are read-only input consulted straight from the posture). Instance-scoped so
+     * concurrent sessions (ACP / AG-UI multi-session) cannot stomp each other's approvals.
      */
-    sessionYolo = false;
+    sessionGrants = new ApprovalGrantStore();
     /**
-     * EXT-9 Tier-2 session allow-list — approved command prefixes that auto-approve for the
-     * life of THIS runner instance. Instance-scoped (not module-global) so concurrent
-     * sessions (ACP / AG-UI multi-session) cannot stomp each other's approvals.
+     * CFG-27 §3 — what the escalation menu's *always reject* choice adds at run time, in the same
+     * grammar ([[TUI-C26]] wires that writer; the store speaks it already). The entries DECLARED in
+     * `approvals.deny` are not here — they are read-only config input, matched from the posture — and
+     * both are handed to the same matcher, so a runtime refusal and a declared one are one list.
      */
-    sessionAllowlist = new AllowlistStore();
+    denyGrants = new ApprovalGrantStore();
     /**
-     * EXT-9 Tier-2 persisted (`always`) allow-list, loaded lazily on first use from
-     * `.gsloth/.gsloth-settings/shell-allowlist.json`. Null until the shell tool is gated
-     * and the allow-list is enabled; null also when persistence is disabled by config.
+     * The persisted (`always`) grant store, loaded lazily on first use from
+     * `.gsloth/.gsloth-settings/shell-allowlist.json`. Null until a gated call actually needs it, and
+     * null when the file cannot be loaded at all (in which case `always` grants degrade to session).
      */
-    persistedAllowlist = null;
-    persistedAllowlistLoaded = false;
+    persistedGrants = null;
+    persistedGrantsLoaded = false;
     /**
      * @param agentFactory Produces the {@link GthAgentInterface} the runner drives.
      *   Defaults to the lean {@link GthLangChainAgent} (core). `@gaunt-sloth/agent`
@@ -91,28 +134,193 @@ export class GthAgentRunner {
         this.toolApprovalCallback = callback;
     }
     /**
-     * EXT-12 — flip the runtime, session-scoped auto-approve flag (the `/auto-approve` /
-     * `/yolo` slash command with no argument). When ON, gated `run_shell_command` calls
-     * auto-approve without prompting for the rest of this session; the hardline floor still applies
-     * at exec time. Returns the NEW state so the caller can render a notice. Session-scoped only —
-     * nothing is written to config.
+     * CFG-27 — switch the session-scoped rung (`/approvals <rung>`). Idempotent; returns the NEW
+     * rung so the caller can render a notice. Session-scoped only — nothing is written to config,
+     * and the declared allow/deny lists are unaffected (they are config input, not session state).
+     */
+    setSessionApprovalRung(rung) {
+        this.sessionApprovals = { ...this.sessionApprovals, rung };
+        return this.sessionApprovals.rung;
+    }
+    /** CFG-27 — the session's current approvals posture (rung + rater profile + declared lists). */
+    getSessionApprovals() {
+        return this.sessionApprovals;
+    }
+    /**
+     * CFG-26 — the allow-list sizes for the `/approvals` display: how many command prefixes the
+     * human has trusted this session, and how many are persisted in the project file.
+     *
+     * READ-ONLY BY CONSTRUCTION: it reports the persisted count only when the store has ALREADY
+     * been loaded (or persistence is on and it can be read), and never through a path that would
+     * CREATE the store as a side effect of showing a display — a status command must not mutate
+     * session state. `always: undefined` therefore means "not loaded / persistence off", which the
+     * caller renders as `—` rather than a misleading `0`.
+     */
+    getAllowlistCounts() {
+        const always = this.persistedGrantsLoaded
+            ? (this.persistedGrants?.size() ?? undefined)
+            : undefined;
+        // EXT-71 §3 — every list MUST be inspectable, and the declared entries are in force for this
+        // session exactly as the human's own grants are. They are counted alongside them rather than
+        // hidden, which is what the count meant before the declared lists stopped seeding the store.
+        const session = this.sessionGrants.size() + this.sessionApprovals.allow.length;
+        return { session, always };
+    }
+    /**
+     * CFG-27 — the session's deny entries for display: the declared `approvals.deny` entries
+     * (rendered one line each) followed by whatever the escalation menu's *always reject* added at
+     * run time. Both refuse a call, so both are shown.
+     */
+    getDenylist() {
+        return [...this.sessionApprovals.deny, ...this.denyGrants.entries()].map(describeApprovalEntry);
+    }
+    /**
+     * §3/§4.7.4 — **the grants themselves**, for an approvals view that shows *what* was granted,
+     * *when*, and *under which effective annotations*. The counterpart of {@link getAllowlistCounts},
+     * which answers only how many.
+     *
+     * The declared config lists are deliberately NOT here. They are something a human wrote and
+     * reviewed, they carry no `grantedAt` and no scope, and `getAllowlistCounts` already counts them
+     * alongside these; mixing them in would present a config line as something the session granted.
+     *
+     * **Read-only in both senses.** It never loads the persisted store — same rule as
+     * {@link getAllowlistCounts}: a display must not create the store in order to show it, so a
+     * session that has not yet needed the file lists its session grants alone. And every grant is
+     * **deep-copied on the way out**, because the stores hand back their live records: the copy on the
+     * way in is what makes a snapshot private to its grant, and handing the same object to a renderer
+     * would put what the gate matches against one property assignment away from any consumer.
+     */
+    getGrants() {
+        const held = [
+            ...this.sessionGrants.list(),
+            ...(this.persistedGrantsLoaded ? (this.persistedGrants?.list() ?? []) : []),
+        ];
+        const seen = new Set();
+        const grants = [];
+        for (const grant of held) {
+            // An `always` grant is written to BOTH stores, so identity de-duplication is what keeps it
+            // from being displayed twice. The same question `ApprovalGrantStore.add` asks.
+            const key = renderApprovalEntryObject(grant.entry);
+            if (seen.has(key))
+                continue;
+            seen.add(key);
+            grants.push({
+                ...grant,
+                entry: copyApprovalEntry(grant.entry),
+                ...(grant.annotations ? { annotations: { ...grant.annotations } } : {}),
+            });
+        }
+        return grants;
+    }
+    /**
+     * §4.7.1 — **which of each server's annotation hints this session believes**, for display.
+     *
+     * Every key either side names is listed: a configured `mcpServers` key with no policy of its own
+     * (which resolves through `defaults`), and a policy key naming a server the config does not have
+     * (which is what a typo looks like). Resolution is {@link trustedAnnotationHints}, the same
+     * function the gate derives effective annotations through, so the display cannot claim a
+     * relationship the gate does not act on.
      */
-    toggleSessionYolo() {
-        this.sessionYolo = !this.sessionYolo;
-        return this.sessionYolo;
+    getMcpAnnotationTrust() {
+        const mcp = this.sessionApprovals.mcp;
+        const configured = new Set(this.configuredMcpServerKeys());
+        const named = Object.keys(mcp?.servers ?? {});
+        const keys = [...new Set([...configured, ...named])];
+        return {
+            defaults: [...(mcp?.defaults?.trustAnnotations ?? [])],
+            servers: keys.map((server) => ({
+                server,
+                trusted: [...trustedAnnotationHints(mcp, server)],
+                configured: configured.has(server),
+            })),
+        };
     }
     /**
-     * EXT-12 — set the session-scoped auto-approve flag explicitly (the `/auto-approve on|off`
-     * slash command). Idempotent; returns the NEW state so the caller can render a notice.
-     * Session-scoped only — nothing is written to config.
+     * §4.7.1 — **believe, or stop believing, specific hints from one server**, for the life of this
+     * session. The runtime half of `approvals.mcp.servers.<key>.trustAnnotations` (§9), so a user can
+     * do from the TUI what they can do in config.
+     *
+     * **Per hint, never per server.** `hints` names the hints this call moves and leaves every other
+     * hint of that server's exactly as it was, because believing a server's `readOnlyHint` while
+     * disbelieving its `openWorldHint` is a coherent position and the common one. A "trust this
+     * server" flag is the design §4.7.1 rejects.
+     *
+     * **The previous set is what was IN FORCE, resolved through `defaults`.** A server not named
+     * under `servers` inherits `defaults`, and naming it makes it state its relationship in full (§9)
+     * — so seeding from the empty set would mean that believing one more hint silently withdrew every
+     * hint `defaults` had granted, which is a weakening the user did not ask for and would invalidate
+     * their grants.
+     *
+     * **Session-scoped only.** Nothing is written to config: the declared block is read-only input
+     * (§9.1), exactly as the rung is.
+     *
+     * A trusted external annotation still never grants more than the same annotation grants one of
+     * our own built-ins — that holds in `core/approvals/annotations.ts` by construction, and this
+     * changes only which hints are read.
      */
-    setSessionYolo(on) {
-        this.sessionYolo = on;
-        return this.sessionYolo;
+    setMcpAnnotationTrust(server, hints, believe) {
+        const mcp = this.sessionApprovals.mcp;
+        const before = trustedAnnotationHints(mcp, server);
+        const requested = new Set(hints);
+        const after = believe
+            ? TOOL_ANNOTATION_HINTS.filter((hint) => before.includes(hint) || requested.has(hint))
+            : TOOL_ANNOTATION_HINTS.filter((hint) => before.includes(hint) && !requested.has(hint));
+        const added = after.filter((hint) => !before.includes(hint));
+        const removed = before.filter((hint) => !after.includes(hint));
+        const nextMcp = {
+            ...mcp,
+            servers: {
+                ...mcp?.servers,
+                [server]: { ...mcp?.servers?.[server], trustAnnotations: after },
+            },
+        };
+        // A fresh posture object, and fresh nested ones above: the resolved posture may share its `mcp`
+        // block with the loaded config, and a session change must not rewrite what the user configured.
+        this.sessionApprovals = { ...this.sessionApprovals, mcp: nextMcp };
+        return {
+            server,
+            configured: this.configuredMcpServerKeys().includes(server),
+            trusted: [...after],
+            added,
+            removed,
+            weakening: removed.filter(trustWithdrawalWeakens),
+            invalidates: this.grantsWeakenedByCurrentTrust(server),
+        };
     }
-    /** EXT-12 — current state of the runtime session-scoped auto-approve flag (see {@link toggleSessionYolo}). */
-    isSessionYolo() {
-        return this.sessionYolo;
+    /**
+     * §4.7.4 — which of this server's saved approvals the trust now in force weakens, for the notice
+     * that reports a trust change. **It predicts; it never removes.** The removal stays where Task
+     * 4 put it — at the call being decided — because that is the only moment the tool's declaration
+     * can be read for certain; here a server that is merely offline declares nothing and would read
+     * as having weakened everything.
+     *
+     * It compares through the same two functions the gate does: the effective-annotation source built
+     * from the posture as it stands *after* the change, and `annotationWeakenings`. A second
+     * comparison written for the display is how a warning comes to describe a rule the gate does not
+     * have.
+     */
+    grantsWeakenedByCurrentTrust(server) {
+        const source = this.effectiveToolAnnotationSource();
+        return this.getGrants()
+            .filter((grant) => grant.entry.type === 'mcpTool' &&
+            grant.entry.server === server &&
+            typeof grant.entry.pattern === 'string' &&
+            grant.annotations !== undefined)
+            .filter((grant) => {
+            // `EffectiveToolAnnotationSource` admits `undefined` for a source that genuinely cannot
+            // answer; `createEffectiveToolAnnotationSource` never returns it — a tool nothing has
+            // declared for resolves to the fail-closed constant, which for a grant made under anything
+            // softer reads as a weakening. The guard is therefore a type-level obligation and not a
+            // live branch: it discharges the union the contract declares, and nothing reaches it.
+            const current = source({
+                kind: 'mcpTool',
+                server,
+                name: grant.entry.pattern,
+                ...(grant.entry.host !== undefined ? { host: grant.entry.host } : {}),
+            });
+            return current !== undefined && annotationWeakenings(grant.annotations, current).length > 0;
+        })
+            .map((grant) => describeApprovalEntry(grant.entry));
     }
     /**
      * Init is split into a separate method. This may create a number of connections,
@@ -130,11 +338,31 @@ export class GthAgentRunner {
         // secret-literal collection walks INLINE config secrets (a pasted `apiKey`/`token` value), not
         // only env-derived ones. Both surfaces (plain observer + Ink TUI) render through this module.
         setToolDisplayConfig(configIn);
-        // EXT-12 — seed the runtime auto-approve flag from the static `run_shell_command.yolo` config so a
-        // config that pre-enables auto-approval starts ON, while the shell tool stays gated (see
-        // GthDeepAgent) and therefore remains toggleable (`/auto-approve off`). Resolved per-command,
-        // mirroring where the shell tool is actually emitted; no effect where the tool is ungated.
-        this.sessionYolo = getEffectiveDevToolsConfig(configIn, command)?.shellYolo === true;
+        // CFG-27 — seed the session posture from config, so a config that pre-selects `bypass` starts
+        // there while the shell tool stays gated (see `resolveShellApprovalGate`) and therefore
+        // remains switchable (`/approvals write`). Resolved per-command, mirroring where the shell
+        // tool is actually emitted; no effect where the tool is ungated.
+        this.sessionApprovals = resolveApprovals(configIn, command);
+        // §3/§9.1 — the DECLARED lists are read-only config input, consulted through the EXT-71 rule
+        // matcher (`core/approvals/matcher.ts`) and NEVER copied into the runtime stores, which hold
+        // only what the escalation menu grants at run time. Both are handed to the same matcher, so
+        // there is one grammar and one comparison, not a config path and a runtime path.
+        this.denyGrants = new ApprovalGrantStore();
+        // CFG-26 — resolve the rater's own model when a profile is named, so the documented mitigation
+        // for a weak model ("point approvals.rater at a stronger one") actually takes effect.
+        //
+        // EAGERLY, here, rather than lazily at first use: `initConfig` re-runs discovery and prints
+        // "Activating profile: …", which mid-turn would write raw over the Ink TUI's managed frame,
+        // and a broken profile should fail at startup rather than three turns in. It deliberately does
+        // NOT catch — a named-but-unusable rater profile is an error, never a silent fallback to the
+        // session model (GS2-62).
+        //
+        // Loaded whenever a profile is NAMED, without a second "will the rater actually run?" gate:
+        // naming a rater profile at an unrated rung is a config the user can hold (they may switch to
+        // `auto-safe` mid-session with `/approvals`), and a broken profile should still fail loudly at
+        // startup rather than at the moment they switch.
+        const raterProfile = this.sessionApprovals.rater;
+        this.raterModel = raterProfile ? await resolveRaterModel(raterProfile) : undefined;
         // Initialize debug logging
         initDebugLogging(configIn.debugLog ?? false);
         debugLog(`Initializing GthAgentRunner with command: ${command || 'default'}`);
@@ -174,6 +402,11 @@ export class GthAgentRunner {
                     result += await this.resolveToolInterrupts();
                 }
                 catch (streamError) {
+                    // CFG-27 — an approvals STOP is not a stream failure: it is the gate deliberately
+                    // ending the run, and its message IS the explanation the spec requires it to carry.
+                    // Re-thrown unchanged (the outer catch does the same) so nothing buries it.
+                    if (streamError instanceof ApprovalStopError)
+                        throw streamError;
                     // Handle streaming-specific errors
                     debugLogError('Stream processing', streamError);
                     throw new Error(`Stream processing failed: ${streamError instanceof Error ? streamError.message : String(streamError)}`);
@@ -213,7 +446,15 @@ export class GthAgentRunner {
             else {
                 // Use non-streaming
                 debugLog('Using non-streaming mode');
-                const result = await this.agent.invoke(messages, this.runConfig);
+                let result = await this.agent.invoke(messages, this.runConfig);
+                // EXT-52 — the SAME interrupt drain the streaming branch does above. A gated
+                // `run_shell_command` suspends the graph, so `invoke` returns with the tool-calling
+                // AIMessage (empty content) as the last message and the command not yet run. Draining here
+                // — BEFORE the empty-response check — is what makes the approval prompt fire and the
+                // approved command's output reach the caller on `streamOutput: false`; without it the turn
+                // died with the misleading empty-response error, so the check may only see a genuinely
+                // empty turn.
+                result += await this.resolveToolInterrupts();
                 debugLog(`Non-stream response length: ${result.length}`);
                 if (result.trim().length === 0) {
                     throw new Error('Model returned an empty response. Try again or switch to a more stable model.');
@@ -222,6 +463,12 @@ export class GthAgentRunner {
             }
         }
         catch (error) {
+            // CFG-27 §4.2/§6.2 — an approvals STOP is not an agent failure and must reach the user with
+            // its own words: the command, the rating and its reason are the whole point of it. Wrapping
+            // it as "Agent processing failed: …" would bury the explanation the spec requires it to
+            // carry, so it is re-thrown unchanged.
+            if (error instanceof ApprovalStopError)
+                throw error;
             // Handle agent invocation errors
             debugLogError('Agent processing', error);
             const originalMessage = error instanceof Error ? error.message : String(error);
@@ -251,7 +498,10 @@ export class GthAgentRunner {
      * streamed across all resume turns (empty when nothing was resumed).
      *
      * No-ops (returns '') when the agent does not support interrupts (`getPendingToolInterrupts`/
-     * `streamResume` absent), so the lean agent and non-HITL configs are unaffected.
+     * `streamResume` absent) — that is the only exemption. As of EXT-52 BOTH backends gate
+     * `run_shell_command` and expose the interrupt surface, so the lean (default) agent is now
+     * exactly the agent this loop serves; only an agent implementation without those methods
+     * (e.g. a test double) skips it.
      */
     async resolveToolInterrupts() {
         const agent = this.agent;
@@ -276,16 +526,106 @@ export class GthAgentRunner {
         return resumedText;
     }
     /**
-     * Decide a single pending tool call (EXT-9 Tier-2). For the opt-in `run_shell_command`,
-     * consult the scoped allow-list FIRST: if the command's classified prefix is already
-     * approved (session or persisted `always`) and survives the safe-bin anti-widening
-     * re-validation, auto-approve SILENTLY (no human prompt). Otherwise fall through to the
-     * human callback; when the human grants `session`/`always` scope, record the command's
-     * classified prefix into the matching store so future flag-variants stop re-prompting.
+     * EXT-71 §3.1/§3.2, EXT-70 §4.7.5 — the subject a pending tool call presents to the rule matcher.
+     *
+     * A gated `run_shell_command` is a **shell** subject and nothing else: it is matched by `shell`
+     * entries, against the command. It is deliberately NOT also offered as a `tool` subject named
+     * `run_shell_command`, which would create a second allow path to every shell command carrying a
+     * different §3.2 `rate` default and a match that never saw the command it was approving.
+     *
+     * **Everything else splits by provenance**, which is the distinction §4.7.1 rests on: `tool` is
+     * the TRUSTED provenance, read verbatim, so an MCP tool arriving as one would be asking the
+     * trusted path for a third party's annotations — a gate any server can opt itself out of. Every
+     * MCP-namespaced name therefore becomes an `mcpTool` subject carrying the user's own `mcpServers`
+     * key, and one whose server cannot be resolved stays an `mcpTool` subject under an unnameable
+     * server rather than falling back to `tool` (see `approvalSubjectForToolName`).
+     *
+     * **The host (§4.7.4)** is attached here, so the one subject the whole decision runs on carries
+     * it: the rule matcher treats a `host` on an entry as an additional exact-match condition, and a
+     * grant the menu writes records it. A call naming no single host has none, which fails toward a
+     * prompt at both sites.
+     *
+     * Widening which tools the gate actually suspends on is still [[EXT-30]]; this decides what a
+     * suspended call *is* whenever one arrives.
+     *
+     * @param hosts Every distinct host the call's arguments name ({@link toolCallHosts}).
+     */
+    approvalSubjectFor(tool, command, hosts) {
+        if (tool.name === SHELL_TOOL_NAME && command !== null)
+            return { kind: 'shell', command };
+        const subject = approvalSubjectForToolName(tool.name, this.configuredMcpServerKeys());
+        return hosts.length === 1 ? { ...subject, host: hosts[0] } : subject;
+    }
+    /**
+     * §4.7.5 — the user's own `mcpServers` keys, the only identity a server has here. Own enumerable
+     * keys via `Object.keys`, so nothing inherited can pose as a configured server.
+     */
+    configuredMcpServerKeys() {
+        const servers = this.config?.mcpServers;
+        return servers && typeof servers === 'object' ? Object.keys(servers) : [];
+    }
+    /**
+     * EXT-70 §4.7.1 — the source a `hint` entry reads a call's EFFECTIVE annotations through, built
+     * from the session's `approvals.mcp` block and the two declared-annotation lookups.
+     *
+     * Built per decision rather than cached at {@link init}, for two reasons that both bite: the
+     * agent registers its tools *inside* `agent.init()`, so an init-time snapshot would be empty; and
+     * a re-init re-resolves the tool list, which for MCP may hand back different declarations.
+     *
+     * The two lookups are deliberately different in kind. `builtIn` reads OUR OWN authored table and
+     * never the bound tool list — the bound list contains every server's tools, and a `builtIn`
+     * lookup over it would read a third party's declaration through the trusted-verbatim path.
+     * `mcp` reads what the servers declared, keyed by the registered tool name so the server key is
+     * never split apart and re-joined differently.
+     */
+    effectiveToolAnnotationSource() {
+        return createEffectiveToolAnnotationSource({
+            mcp: this.sessionApprovals.mcp,
+            declared: {
+                builtIn: builtInToolAnnotations,
+                mcp: mcpDeclaredAnnotationLookup(this.agent?.getDeclaredMcpToolAnnotations?.()),
+            },
+        });
+    }
+    /**
+     * Decide a single pending tool call. Spec order — **deny → bypass → escalate → allow → rater →
+     * human prompt**, with the hardline floor at exec time regardless. The two adjacencies that carry
+     * the design are that deny comes BEFORE `bypass` and escalate comes AFTER it:
+     *
+     * 1. **deny** (§3) — a declared entry or a runtime *always reject* grant is refused with no
+     *    prompt and no rating call. It is consulted FIRST, and it is the one
+     *    check that **still applies under `bypass`**: choosing `bypass` says *"stop asking me"*, not
+     *    *"forget what I told you never to do"*. A deny entry MAY match a compound command, because a
+     *    prohibition that catches something unresolvable errs in the direction that costs nothing.
+     * 2. **`bypass`** — the gate is off for this session; approve at scope `once`.
+     * 3. **escalate** (§3.2) — a declared entry always asks the human, whatever the rung would have
+     *    done, **including outranking the automatic grants of `read-only` and `write`** and any allow
+     *    entry that also matched. It goes straight to the human with **no rating call**, and it never
+     *    enters the `full-auto` negotiation. It is **inert at `bypass`**, which is why it sits below
+     *    the rung check: the rung chosen for this session wins, and a stop that must survive `bypass`
+     *    is a deny entry and only that.
+     * 4. **allow** (§3, §3.2) — a declared entry or a grant the human made at an earlier prompt this
+     *    session (or persisted), matched against the whole normalized command and only when that
+     *    command statically resolves. An allow match settles the human's part: no prompt. Whether the rater
+     *    still reviews the call is the entry's own `rate` (§3.2) — honored at the rater rungs and
+     *    inert at the deterministic ones, so no entry can smuggle a model call into `read-only` or
+     *    `write` — and a rated allow match is a TRIPWIRE, not a re-adjudication
+     *    ({@link mapAllowMatchedVerdictToAction}).
+     * 5. **auto-rater** (`auto-safe` / `full-auto` only) — `safe` approves, `destructive` and
+     *    `catastrophic` escalate, and `attack` HALTS the run ({@link AttackHaltError}). The other
+     *    three rungs consult no model at all. At those same two rungs a **tool** call is instead
+     *    floored deterministically by §4.7.3's open-world rule ({@link openWorldToolFloorReason} into
+     *    {@link applyDestructiveFloor} — the one floor the shell path also reaches): a call whose
+     *    effective `openWorldHint` is true is `destructive`, whatever its `readOnlyHint` says.
+     * 6. **human prompt** — the approval callback; when the human grants `session`/`always` scope,
+     *    **that command** is recorded as an `exact` entry (§3.1/§6 — the menu never widens), so the
+     *    same command stops re-prompting and a longer variant of it still asks.
      *
-     * When no human callback is wired (non-TTY exec run) and nothing is allow-listed, reject —
-     * never auto-approve. Non-shell tools (or any tool when the allow-list is disabled) skip the
-     * allow-list and go straight to the human callback / default-reject, preserving prior behaviour.
+     * §6.2 — where no human can answer (CI, a one-shot run, a server), an escalation is **not** a
+     * rejection handed back to the model: it is an immediate non-zero exit
+     * ({@link NonInteractiveEscalationError}) carrying the command, the rating and its reason. No
+     * prompt, no waiting, and never a timeout into approval. Declaring commands in `approvals.allow`
+     * is the supported way to make a pipeline pass.
      *
      * Hardline catastrophic commands remain refused at exec time regardless of any approval here
      * (defense in depth in `GthDevToolkit.executeCommand`), so an allow-listed `rm -rf /` still
@@ -293,123 +633,448 @@ export class GthAgentRunner {
      */
     async decideToolApproval(tool) {
         const command = typeof tool.args?.command === 'string' ? tool.args.command : null;
-        const isShellCommand = tool.name === 'run_shell_command' && command !== null;
-        const allowlistApplies = isShellCommand && this.isShellAllowlistOn();
-        // EXT-12 — runtime session yolo (`/yolo`): when ON, auto-approve a gated shell command WITHOUT
-        // prompting, judging, or persisting. Scope `once` so nothing is written to the allow-list (the
-        // bypass is intentionally ephemeral and reversible). The hardline floor is NOT bypassed here —
-        // it is enforced at exec time in GthDevToolkit.executeCommand regardless of this decision, so a
-        // catastrophic command is still refused even under yolo.
-        if (isShellCommand && this.sessionYolo) {
-            return { type: 'approve', scope: 'once' };
+        const isShellCommand = tool.name === SHELL_TOOL_NAME && command !== null;
+        const approvals = this.sessionApprovals;
+        // ONE subject and ONE annotation source per decision, shared by the rule matcher and the
+        // §4.7.3 floor below. Building a second source for the floor would let a `hint` entry and the
+        // floor read different effective values for the same call — the two-derivations-disagreeing
+        // failure `core/approvals/annotations.ts` exists to prevent.
+        // §4.7.4 — the hosts this call names, read ONCE. The subject carries the single host where
+        // there is exactly one; the sticky-grant decision needs the count as well, because "named no
+        // host" and "named several" are the same absent `host` on the subject and are not the same
+        // question for the menu.
+        const hosts = tool.name === SHELL_TOOL_NAME && command !== null ? [] : toolCallHosts(tool.args);
+        const subject = this.approvalSubjectFor(tool, command, hosts);
+        const annotationSource = this.effectiveToolAnnotationSource();
+        // ONE read of that source per decision as well, so the §4.7.4 invalidation below, the §4.7.3
+        // floor and the snapshot a grant records are all the same set. A shell subject has none — a
+        // command carries no tool annotations.
+        const effective = subject.kind === 'shell' ? undefined : annotationSource(subject);
+        // §4.7.4 — **before any rule is resolved**, so a grant the tool has since weakened out from
+        // under cannot auto-approve the very call that revealed the weakening.
+        if (subject.kind !== 'shell' && effective)
+            this.invalidateWeakenedGrants(subject, effective);
+        // The declared lists AND the runtime grant stores, resolved most-restrictive-wins in ONE pass
+        // through the ONE comparison engine, so author order and the order the lists were concatenated
+        // in cannot change the outcome — and a grant the menu wrote is compared exactly as a line the
+        // user typed into their config is.
+        const rule = resolveApprovalRules(subject, this.approvalRuleLists(), {
+            // EXT-70 §4.7.1 — a `hint` entry reads EFFECTIVE annotations, which is where per-server,
+            // per-hint trust is applied. Without this the matcher falls back to the fail-closed source,
+            // where no tool is ever read-only and a `hint` entry could only ever describe the default.
+            annotations: annotationSource,
+            onNotice: (notice) => this.statusUpdate(notice.level, notice.message),
+        });
+        // (1) Deny — before everything, including `bypass`.
+        if (rule?.action === 'deny') {
+            return {
+                type: 'reject',
+                message: `Refused: your deny list forbids this call (matched "${describeApprovalEntry(rule.entry)}"). ` +
+                    'Remove the entry from approvals.deny if you want it to run.',
+            };
         }
-        // Auto-approve from the allow-list without prompting. The allow-list ALWAYS wins over the
-        // judge: a human-trusted prefix shouldn't pay for an LLM call on every variant.
-        if (allowlistApplies && this.isApprovedByAllowlist(command)) {
-            return { type: 'approve', scope: 'session' };
+        // (2) `bypass` (config or `/approvals bypass`): approve a gated shell command WITHOUT
+        // prompting or rating. Scope `once` so nothing is written to the allow-list (the bypass is
+        // intentionally ephemeral and reversible). The hardline floor is NOT bypassed here — it is
+        // enforced at exec time in GthDevToolkit.executeCommand regardless of this decision.
+        if (isShellCommand && approvals.rung === 'bypass') {
+            return { type: 'approve', scope: 'once' };
         }
-        // EXT-10 — LLM-as-judge safety gate (default OFF). Runs BEFORE the human callback for a
-        // `run_shell_command` not already allow-listed: auto-approve clearly-safe (fatigue reducer),
-        // reject clearly-catastrophic (only when blockHigh), otherwise fall through to the human with
-        // the verdict attached. When disabled this is a no-op and behaviour is exactly EXT-9.
+        // (3) Escalate — §3.2 sends it straight to the human with no rating call, outranking any allow
+        // entry that also matched.
+        //
+        // The `bypass` term is deliberate and not redundant with the early return above. That return
+        // only covers a SHELL call, so without this term a non-shell subject would still carry an
+        // escalate match into the prompt at `bypass` — unreachable while `run_shell_command` is the
+        // only gated tool, but §2.5's rule is about the rung, not about which tool asked. Make the
+        // invariant true rather than incidentally true, so [[EXT-30]] widening the gate cannot quietly
+        // break it.
+        const escalatedBy = rule?.action === 'escalate' && approvals.rung !== 'bypass'
+            ? describeApprovalEntry(rule.entry)
+            : undefined;
+        // (4) Approve from the allow list without prompting. It ALWAYS wins over the rater — a
+        // human-trusted call shouldn't pay for an LLM call on every variant — but never over escalate.
+        const allowlistApplies = approvals.rung !== 'bypass' && escalatedBy === undefined;
         let safetyVerdict;
-        if (isShellCommand && command !== null && this.isShellJudgeOn()) {
-            const settings = getShellJudgeSettings(getEffectiveDevToolsConfig(this.config ?? undefined, this.command));
-            const verdict = await judgeShellCommand(command, this.config, {
-                home: env?.HOME,
-            });
-            const action = mapVerdictToAction(command, verdict, {
-                autoApproveLow: settings.autoApproveLow,
-                blockHigh: settings.blockHigh,
-            });
-            if (action === 'auto-approve') {
-                // Scope `once`: judge approvals are NEVER persisted to the allow-list.
-                return { type: 'approve', scope: 'once' };
+        if (allowlistApplies && rule?.action === 'allow') {
+            // §3.2 — `rate` is honored at the rater rungs and INERT at the deterministic ones, so an
+            // entry can never smuggle a model call into `read-only` or `write`. A tool subject is not
+            // rated either: the rater's first implementation covers the shell only (§4.3, [[EXT-30]]).
+            if (!rule.rate || !isRatedRung(approvals.rung) || !isShellCommand || command === null) {
+                return { type: 'approve', scope: 'session' };
             }
-            if (action === 'reject') {
-                return {
-                    type: 'reject',
-                    message: `Safety judge blocked the command: ${verdict.reason}`,
-                };
+            const verdict = await this.rateCommand(command, { allowMatched: true });
+            const tripwire = mapAllowMatchedVerdictToAction(verdict);
+            if (tripwire.action === 'approve')
+                return { type: 'approve', scope: 'session' };
+            if (tripwire.action === 'halt') {
+                // §3.2/§4.2 — `attack` halts exactly as it would have without the match. A standing human
+                // grant answers "may this run"; it does not answer "is this command's structure hostile".
+                throw new AttackHaltError(command, tripwire.verdict?.reason ?? '');
+            }
+            // `catastrophic` — the one outcome the tripwire escalates. Fall through to the human.
+            safetyVerdict = tripwire.verdict;
+        }
+        // (5) What the gate makes of the call itself, at the two rated rungs only. Skipped entirely
+        // for an escalate match (§3.2: the user pre-decided that a human answers, so a rating would
+        // decorate a mandatory prompt) and for a call the tripwire above already rated. The rung test
+        // is the SAME one `mapVerdictToAction` applies, so both arms below floor exactly where the
+        // shell does and nowhere else: `bypass` and the two deterministic rungs consult neither the
+        // rater nor a preflight, and at those rungs the human is asked regardless.
+        if (isRatedRung(approvals.rung) && escalatedBy === undefined && safetyVerdict === undefined) {
+            // **The SUBJECT is what splits the two arms, not a second reading of the tool name.**
+            // `approvalSubjectFor` returns `kind: 'shell'` under exactly the condition `isShellCommand`
+            // states, so branching on the discriminant says the same thing once instead of twice — and
+            // any future divergence in that function sends the call to the FLOOR (fail-closed) rather
+            // than silently past it. It is also what carries the command as a non-null string.
+            if (subject.kind === 'shell') {
+                // The auto-rater. `safe` is approved (the fatigue reducer), `destructive` and
+                // `catastrophic` fall through to the human with the verdict attached, and `attack` ends
+                // the run outright. §4.6's deterministic preflights are applied inside
+                // `mapVerdictToAction`, ahead of the `safe` check.
+                const verdict = await this.rateCommand(subject.command, { allowMatched: false });
+                const decision = mapVerdictToAction(subject.command, verdict, { rung: approvals.rung });
+                if (decision.action === 'approve') {
+                    // Scope `once`: rater approvals are NEVER persisted to the allow-list.
+                    return { type: 'approve', scope: 'once' };
+                }
+                if (decision.action === 'halt') {
+                    // §4.2 — not a rejection the model can respond to. It ends the agent loop.
+                    throw new AttackHaltError(subject.command, decision.verdict?.reason ?? '');
+                }
+                // Escalate: carry the verdict (the honest one — see mapVerdictToAction) to the human.
+                safetyVerdict = decision.verdict;
+            }
+            else {
+                // EXT-70 §4.7.2/§4.7.3 — a tool call whose EFFECTIVE `openWorldHint` is true is floored at
+                // `destructive`, through the SAME `applyDestructiveFloor` the shell path reaches via
+                // `mapVerdictToAction`. No rating call: §4.3's scope boundary keeps the rater on the shell
+                // until [[EXT-30]], and the floor is deterministic anyway — §4.6 states it as coming
+                // *before* any model call, so it does not wait for one.
+                //
+                // **This is the branch a malformed `run_shell_command` lands in**, and it is the one shape
+                // that reaches this floor under today's gate: a call with no `command` argument, or one
+                // that is not a string, has nothing to rate, so it presents as a `tool` subject — and
+                // `run_shell_command` carries no authored annotations, so its effective set is the
+                // fail-closed one and it floors. That is the right direction: a shell call whose command
+                // cannot even be read is not one anything can say something reassuring about.
+                //
+                // The annotations are the effective set (§4.7.1), read through the same source the `hint`
+                // matcher just used, so an untrusted server's `openWorldHint: false` has already collapsed
+                // to the fail-closed `true` and cannot buy its way past this.
+                //
+                // Reached only when no allow entry claimed the call: §4.6's fourth bullet makes an allow
+                // match lift this floor, and step (4) above has already returned in that case.
+                safetyVerdict = applyDestructiveFloor(safetyVerdict, openWorldToolFloorReason(effective));
             }
-            // Escalate: carry the verdict to the human approval surface.
-            safetyVerdict = verdict;
         }
         if (!this.toolApprovalCallback) {
-            // No interactive handler (e.g. non-TTY exec run): reject rather than auto-approve.
-            return {
-                type: 'reject',
-                message: 'Tool call rejected: no interactive approval handler available.',
-            };
+            // §6.2 — no one to ask. Exit non-zero with everything a person needs, rather than handing
+            // the model a rejection it would just work around.
+            throw new NonInteractiveEscalationError(command ?? tool.name, safetyVerdict?.outcome, safetyVerdict?.reason, escalatedBy);
         }
-        // Surface the judge's verdict to the human prompt (if the judge escalated) without mutating
-        // the original interrupt object the caller holds.
-        const pending = safetyVerdict ? { ...tool, safetyVerdict } : tool;
+        // §4.2 — **a `catastrophic` approval is NEVER sticky.** "The human may approve this one
+        // invocation, and only this one": no always-allow, and no session-scoped allow either. The
+        // surface withdraws the affordance ([[TUI-C26]] drops `always approve` from the menu for this
+        // outcome), but the allow-list WRITE is decided here, and §3 has the allow-list consulted
+        // *before* the rater — so one sticky grant would remove the command from rating permanently,
+        // and the next `terraform destroy` would never be rated at all. Clamping here means the policy
+        // does not depend on which surface asked, or on a surface that has not been built yet.
+        const catastrophic = safetyVerdict?.outcome === 'catastrophic';
+        // §6 — **the menu must display what it is about to store**, at the moment of the choice, on
+        // every surface. It is rendered from the very grant {@link recordApproval} will write, because a
+        // menu that describes a grant one way and stores it another is the drift this design cannot
+        // afford. Absent exactly where no sticky grant is available — a `catastrophic` outcome (§4.2
+        // withdraws the persistent grants for EVERY subject, not only the shell one), or a call nothing
+        // would remember — so the prompt never advertises a control that has already been withdrawn.
+        const grant = catastrophic ? undefined : this.stickyGrantFor(subject, effective, hosts);
+        const grantPreview = grant ? renderApprovalEntryObject(grant.entry) : undefined;
+        // §6 — the same grant in the words the menu's *always approve* control is written in, through
+        // the one-liner the §4.7.4 withdrawal notice also uses, so the two cannot describe one grant
+        // two ways. For a tool call this is where "the stored thing is the tool, not the arguments"
+        // becomes visible: it names the tool, its server and the host bound, and nothing else.
+        const grantSummary = grant ? describeApprovalEntry(grant.entry) : undefined;
+        // Surface the rater's verdict, the escalate entry that fired as provenance (§3.2), and what a
+        // sticky choice would store (§6) — without mutating the original interrupt object the caller
+        // holds.
+        const pending = safetyVerdict || escalatedBy || grantPreview
+            ? {
+                ...tool,
+                ...(safetyVerdict ? { safetyVerdict } : {}),
+                ...(escalatedBy ? { escalatedBy } : {}),
+                ...(grantPreview ? { grantPreview } : {}),
+                ...(grantSummary ? { grantSummary } : {}),
+            }
+            : tool;
         const decision = await this.toolApprovalCallback(pending);
-        // Persist the human's scoped grant so future variants of the same operation skip the prompt.
-        if (decision.type === 'approve' && allowlistApplies && command) {
-            this.recordApproval(command, decision.scope ?? 'once');
+        // Record the human's scoped grant so the same call stops re-prompting.
+        if (decision.type === 'approve' && grant) {
+            this.recordApproval(grant, decision.scope ?? 'once');
         }
         return decision;
     }
-    /** Whether the EXT-10 LLM-as-judge safety gate is enabled for the active command's config. */
-    isShellJudgeOn() {
-        if (!this.config)
-            return false;
-        const devTools = getEffectiveDevToolsConfig(this.config, this.command);
-        return isShellJudgeEnabled(devTools);
-    }
-    /** Whether the EXT-9 Tier-2 allow-list is enabled for the active command's devTools config. */
-    isShellAllowlistOn() {
-        const devTools = getEffectiveDevToolsConfig(this.config ?? undefined, this.command);
-        return isShellAllowlistEnabled(devTools);
-    }
-    /**
-     * Lazily load (once per instance) the persisted `always` allow-list, unless persistence is
-     * disabled by config. Returns null when persistence is off so `always` grants behave as
-     * `session` (in-memory only).
-     */
-    getPersistedAllowlist() {
-        if (this.persistedAllowlistLoaded)
-            return this.persistedAllowlist;
-        this.persistedAllowlistLoaded = true;
-        const devTools = getEffectiveDevToolsConfig(this.config ?? undefined, this.command);
-        if (!isShellAllowlistPersisted(devTools)) {
-            this.persistedAllowlist = null;
-            return null;
+    /**
+     * One rating call, with EXT-66's timeout reporting attached. Extracted so the §3.2 tripwire (a
+     * rated allow match) and the ordinary rater path cannot drift apart in WHAT they hand the rater —
+     * only in what they do with the answer.
+     */
+    async rateCommand(command, opts) {
+        const approvals = this.sessionApprovals;
+        const verdict = await rateShellCommand(command, this.config, {
+            home: env?.HOME,
+            // The profile's model when one is configured; undefined lets rateShellCommand use the
+            // session model. `init` throws rather than leaving this undefined for a NAMED profile, so
+            // a configured profile can never silently degrade to the session model here.
+            model: this.raterModel,
+            // EXT-58 (§4.4) — the already-granted built-ins of the CURRENT rung, so a non-`safe`
+            // outcome can name one the model could call for free instead. Computed per rating rather
+            // than cached at init, because `/approvals <rung>` moves the rung mid-session and a stale
+            // list would offer a tool that is no longer granted.
+            grantedTools: this.getGrantedBuiltInTools(),
+            // EXT-66 — the user-owned budget for ONE rating call, `undefined` when unset so
+            // rateShellCommand applies RATER_DEFAULT_TIMEOUT_MS. 30s is a hosted-model number and a
+            // local rater is knowably slower; without this a local `full-auto` session drifts toward
+            // escalating everything, which is the failure the rung exists to prevent.
+            timeoutMs: approvals.raterTimeoutMs,
+        });
+        // EXT-66 — a timeout is the gate giving up, not a judgement, and the two were previously
+        // indistinguishable in the action column. Say it once per occurrence: the only symptom
+        // otherwise is the gate becoming mysteriously more talkative, which reads as the rater
+        // working rather than as the rater never being heard from.
+        if (isRaterTimeout(verdict)) {
+            this.raterTimeouts += 1;
+            this.statusUpdate(StatusLevel.WARNING, `The command safety rater did not answer in time (${approvals.raterTimeoutMs ?? RATER_DEFAULT_TIMEOUT_MS}ms), so this command ` +
+                // §3.2 — on an allow match the rating is a tripwire, so a timeout does not escalate: the
+                // human's standing grant still stands and the call runs. Saying "escalated" there would
+                // be simply false, and a notice that misreports the action it accompanies is worse than
+                // none.
+                (opts.allowMatched
+                    ? 'ran on its approvals.allow match alone, without the rating that entry asked for'
+                    : 'was escalated without being rated') +
+                (this.raterTimeouts > 1 ? ` — ${this.raterTimeouts} times this session` : '') +
+                '. Raise approvals.raterTimeoutMs if the rater is a local model.');
         }
+        return verdict;
+    }
+    /**
+     * EXT-58 (§4.3/§4.4) — the built-in tools already granted at the session's CURRENT rung, as
+     * names plus one-line locally-authored descriptions, for the rater prompt.
+     *
+     * Two filters make this safe to place outside the rater's fenced untrusted block:
+     * - the names come from what the agent actually registered
+     *   ({@link GthAgentInterface.getRegisteredToolNames}), so the rater can only ever offer a tool
+     *   this session has;
+     * - the descriptions come from core's own `BUILT_IN_TOOL_SUMMARIES` table, so no MCP, custom or
+     *   A2A tool's own (attacker-influenceable) description can reach the prompt.
+     *
+     * Empty when the agent does not expose its tools — the rater then gets no list and, per the
+     * prompt, offers nothing.
+     */
+    getGrantedBuiltInTools() {
+        const registered = this.agent?.getRegisteredToolNames?.() ?? [];
+        if (registered.length === 0)
+            return [];
+        // The gated set is resolved from the SAME shared policy both backends wire their interrupt
+        // from, so "granted" here means exactly what it means at tool-registration time (§4.5).
+        const { gateShell } = resolveShellApprovalGate(this.config ?? undefined, this.command);
+        const gatedTools = gateShell ? [SHELL_TOOL_NAME] : [];
+        return describeGrantedBuiltInTools(registered, this.sessionApprovals.rung, gatedTools);
+    }
+    /**
+     * §3/§3.3 — the three rule lists this session decides by: the DECLARED entries from config
+     * (read-only input) concatenated with the runtime grants the escalation menu made. One set of
+     * lists, handed to the one comparison engine; the concatenation cannot change any outcome
+     * because `resolveApprovalRules` consults every deny entry before any escalate entry and every
+     * escalate entry before any allow entry.
+     *
+     * The persisted store is loaded here rather than at {@link init} — lazily, once per instance, and
+     * NEVER at `bypass`, where the allow list is moot and a session that has switched the gate off
+     * should not be reading or rewriting the project's grant file.
+     */
+    approvalRuleLists() {
+        const approvals = this.sessionApprovals;
+        const persisted = approvals.rung === 'bypass' ? null : this.getPersistedGrants();
+        return {
+            deny: [...approvals.deny, ...this.denyGrants.entries()],
+            escalate: approvals.escalate,
+            allow: [...approvals.allow, ...this.sessionGrants.entries(), ...(persisted?.entries() ?? [])],
+        };
+    }
+    /**
+     * Lazily load (once per instance) the persisted `always` grant store.
+     *
+     * CFG-27 removed the `persistAllowlist` switch: §3 makes persistence a per-decision choice in
+     * the escalation menu (`approve` forgets, `always approve` persists), and a global "never
+     * persist" setting would only duplicate a keystroke. Returns null when the store cannot be
+     * loaded at all, in which case `always` grants degrade to `session` (in-memory only).
+     *
+     * The v1→v2 migration notice is routed to `statusUpdate` from here, which is the only place that
+     * knows how to reach the user.
+     */
+    getPersistedGrants() {
+        if (this.persistedGrantsLoaded)
+            return this.persistedGrants;
+        this.persistedGrantsLoaded = true;
         try {
             const filePath = getGslothConfigWritePath(SHELL_ALLOWLIST_FILE);
-            this.persistedAllowlist = new PersistedAllowlist(filePath);
+            this.persistedGrants = new PersistedApprovalGrants(filePath, {
+                onNotice: (notice) => this.statusUpdate(notice.level, notice.message),
+            });
         }
         catch (e) {
             // Path/IO failure → behave as no persisted store (still safe: just prompts more).
-            debugLogError('Loading persisted shell allow-list', e);
-            this.persistedAllowlist = null;
+            debugLogError('Loading persisted shell approvals', e);
+            this.persistedGrants = null;
         }
-        return this.persistedAllowlist;
+        return this.persistedGrants;
     }
-    /** Check the command against the session + persisted stores (with anti-widening re-validation). */
-    isApprovedByAllowlist(command) {
-        return matchesApproval(command, {
-            session: this.sessionAllowlist,
-            always: this.getPersistedAllowlist() ?? undefined,
-        });
+    /**
+     * §3.1/§4.7.4/§6 — **the grant a sticky choice would write for this call**, or `undefined` when
+     * none is on offer. The one place that question is answered, so the menu's *this is what will be
+     * stored* line (§6) and the store can never disagree.
+     *
+     * - **A shell call** records the command itself as an `exact` entry (§3.1) — never a prefix,
+     *   never a pattern. One that does not statically resolve (composition, substitution,
+     *   redirection) is not on offer: no allow entry of any matcher matches such a command, so the
+     *   entry would be inert, and an inert entry sitting in a list §3 requires to be inspectable
+     *   tells the user something is in force when nothing is.
+     * - **A tool call** records identity — the tool, its server, and the host where the call carries
+     *   one (§4.7.4, {@link toolGrantEntry}) — never arguments, which would produce a grant that
+     *   never matches twice. A call naming no host records the tool alone, which is §6's own example
+     *   (*always approve `mcp__jira__create_issue`*, where no host is involved); what keeps that from
+     *   being unbounded is §3.2's default that a tool entry is still `rate: true`, so the rater goes
+     *   on seeing every call's full arguments.
+     *
+     * Four cases have **no grant on offer at all**, each fail-closed:
+     *
+     * 1. **`bypass`** — the gate is off for this session and nothing is remembered from it.
+     * 2. **`run_shell_command` arriving as a tool subject.** That is what a shell call with no
+     *    readable `command` argument presents as, and it names no host, so without this it would take
+     *    the tool-only arm and write a `{"type":"tool","pattern":"run_shell_command"}` grant that
+     *    auto-approves every future call whose command cannot even be read. This exclusion is what
+     *    stops that, not a side effect of anything else, and it must survive [[EXT-30]] widening the
+     *    gate.
+     * 3. **A call naming more than one distinct host.** The grammar has no entry for it. `host` is a
+     *    single optional string on every tool arm of `approvalEntrySchema`, and every arm is a
+     *    `z.strictObject`, so recording the *set* is not a policy this code may choose — a `hosts`
+     *    array is an unrecognized-key error, and writing one would be a §3.1 grammar change. Of the
+     *    two entries that would parse, the host-bound one displays a bound the grant does not have,
+     *    which §6 forbids (the menu shows exactly what will be stored). And a grammar that did record
+     *    the set, matching only when all of it recurred, would fail §4.7.4's opening test anyway: a
+     *    tool whose host set varies per call would get a grant that never matches a second time — not
+     *    a narrower grant, the useless one §4.7.4 rejects by name.
+     *
+     *    **What this arm does not claim.** It is not a narrowing. A hostless entry imposes no host
+     *    condition at all (`resolveApprovalRules`), so the tool-only grant that any host-less call to
+     *    the same tool produces already auto-approves a multi-host one. Refusing here withholds a
+     *    grant; it does not close a hole, and the reason to keep it is the grammar above rather than
+     *    any breadth it prevents. Asserted, so this cannot drift back into a claim the system does not
+     *    support.
+     * 4. **An MCP call whose server could not be resolved** ({@link toolGrantEntry} returns `null`) —
+     *    a call nobody can attribute is not one anything can remember.
+     */
+    stickyGrantFor(subject, effective, hosts) {
+        if (this.sessionApprovals.rung === 'bypass')
+            return undefined;
+        if (subject.kind === 'shell') {
+            if (classifyCommand(subject.command, normalizeCommand) === null)
+                return undefined;
+            return { entry: shellGrantEntry(subject.command) };
+        }
+        if (subject.name === SHELL_TOOL_NAME)
+            return undefined;
+        // A snapshot is what invalidation compares against, so a grant with no readable effective set
+        // is a grant nothing could ever invalidate.
+        if (!effective)
+            return undefined;
+        if (hosts.length > 1)
+            return undefined;
+        const entry = toolGrantEntry(subject);
+        if (!entry)
+            return undefined;
+        // §4.7.4 — the effective set the human approved this tool AS. `annotationWeakenings` compares a
+        // later one against it, and the store copies it so the record is private to this grant.
+        return { entry, annotations: effective };
     }
     /**
-     * Record a human-granted approval at the given scope. `once` persists nothing. `session`
-     * adds the classified prefix to the in-memory store. `always` additionally persists it (or
-     * falls back to session-only when persistence is disabled).
+     * §3.1/§6 — record a human-granted approval at the given scope. `once` remembers nothing.
+     * `session` adds the entry to the in-memory store; `always` additionally persists it (falling
+     * back to session-only when the file cannot be written).
+     *
+     * What is recorded was decided by {@link stickyGrantFor} and shown to the human before they
+     * answered; this only stamps it with when and at what scope.
      */
-    recordApproval(command, scope) {
+    recordApproval(grant, scope) {
         if (scope === 'once')
             return;
-        const classification = classifyCommand(command, normalizeCommand);
-        if (!classification)
-            return; // unclassifiable (composition/redirection) → never remember.
-        this.sessionAllowlist.add(classification.prefix);
+        const grantScope = scope;
+        const record = {
+            ...grant,
+            grantedAt: new Date().toISOString(),
+            scope: grantScope,
+        };
+        this.sessionGrants.add(record);
         if (scope === 'always') {
-            this.getPersistedAllowlist()?.add(classification.prefix);
+            this.getPersistedGrants()?.add(record);
+        }
+    }
+    /**
+     * §4.7.4 — **drop a tool grant the tool has since weakened out from under, with a notice naming
+     * the tool, the server and the hint that moved.**
+     *
+     * The human approved a tool *as annotated*; a tool that re-annotates itself into a more dangerous
+     * shape is a different proposition wearing the same name, so the grant is invalidated and the next
+     * call prompts again. Only a **trusted** server can produce a weakening — an untrusted server's
+     * effective set is the constant fail-closed default (§4.7.1) and cannot move — which is exactly
+     * where it matters, since the trusted server is the one whose rug-pull would otherwise ride an
+     * existing grant.
+     *
+     * **Scoped to the call being decided, never a sweep of the store.** A sweep would read every held
+     * grant against a source that can only answer for the tools registered right now, so a server that
+     * happened to be offline would read as having weakened everything it ever declared — and the
+     * grants would be deleted for it.
+     *
+     * **The scope is every grant that could auto-approve THIS call, which is at most two.** A grant
+     * with no `host` imposes no host condition, so it matches a call that carries one; looking up only
+     * the entry this call would grant (`host` included) would miss the tool-only grant that is about
+     * to auto-approve it, and the weakening would ride straight through — the exact failure §4.7.4
+     * exists to stop. The host-bound entry of a DIFFERENT host is deliberately not a candidate: it
+     * does not match this call either, so this call's annotations say nothing about it.
+     *
+     * **Only allow-side grants.** A weakening makes a tool more dangerous, so dropping an *always
+     * reject* over one would be the unsafe direction: the reason to withdraw an approval is the reason
+     * to keep a refusal.
+     */
+    invalidateWeakenedGrants(subject, effective) {
+        const candidates = [
+            toolGrantEntry(subject),
+            ...(subject.host !== undefined ? [toolGrantEntry({ ...subject, host: undefined })] : []),
+        ].filter((entry) => entry !== null);
+        if (candidates.length === 0)
+            return;
+        // Never at `bypass`, for the same reason `approvalRuleLists` does not read the file there: a
+        // session that has switched the gate off should not be rewriting the project's grant file.
+        const persisted = this.sessionApprovals.rung === 'bypass' ? null : this.getPersistedGrants();
+        for (const entry of candidates) {
+            // The session store wins, and a session grant with no snapshot therefore hides a persisted one
+            // that has one. Safe only because all three of these hold, and each is a premise a later change
+            // could break silently: (1) every tool grant this runner writes carries a snapshot — a call with
+            // no readable effective set is refused a grant at all ({@link stickyGrantFor}); (2) a `shell`
+            // subject, the one kind whose grant has no snapshot by design, never reaches this method; and
+            // (3) a persisted grant already in force auto-approves the call, so no prompt happens and no
+            // session grant is written over it. Break any one of them and this line starts skipping a
+            // weakening it should have caught — check both stores then, rather than the first that answers.
+            const held = this.sessionGrants.find(entry) ?? persisted?.find(entry);
+            if (!held?.annotations)
+                continue;
+            const weakened = annotationWeakenings(held.annotations, effective);
+            if (weakened.length === 0)
+                continue;
+            // Removed rather than skipped: the stores de-duplicate by entry identity, so a grant left in
+            // place would silently swallow the human's re-approval of the same tool.
+            this.sessionGrants.remove(entry);
+            persisted?.remove(entry);
+            this.statusUpdate(StatusLevel.WARNING, describeWeakenedGrant(entry, weakened, held.annotations, effective));
         }
     }
     /**
@@ -427,7 +1092,7 @@ export class GthAgentRunner {
      * leaves the graph suspended on a `humanInTheLoopMiddleware` interrupt rather than
      * completing. This is the event-stream counterpart to the readline path's
      * {@link resolveToolInterrupts}: it drains any pending interrupts through
-     * {@link decideToolApproval} (allow-list → judge → bridged human prompt), resumes via
+     * {@link decideToolApproval} (bypass → allow-list → rater → bridged human prompt), resumes via
      * `streamWithEventsResume({ decisions })`, and loops until the graph completes with no
      * pending interrupts — so the executed command's output renders into the TUI. Without
      * this the TUI silently finalized an empty turn (approval gate was dead code on the
@@ -451,15 +1116,18 @@ export class GthAgentRunner {
      * resolve any tool-approval interrupts it suspended on, yielding the resumed run's typed
      * {@link AgentStreamEvent}s so the renderer (the Ink TUI) shows the executed command's
      * output. Each pending tool call is consulted via {@link decideToolApproval} — the SAME
-     * three-layer gate the readline path uses (allow-list auto-approve → EXT-10 judge →
+     * gate the readline path uses (bypass → allow-list approve → CFG-26 AI rater →
      * bridged human callback, defaulting to REJECT when no handler is wired) — and the
      * collected decisions are sent back via `streamWithEventsResume` as a LangChain HITL
      * resume (`{ decisions }`). Because a resumed run can suspend again on the next gated
      * tool call, this loops until the graph completes with no pending interrupts.
      *
      * No-ops (yields nothing) when the agent does not support interrupts
-     * (`getPendingToolInterrupts`/`streamWithEventsResume` absent), so the lean agent and
-     * non-HITL configs are unaffected. Aborts (`signal`) propagate through the resumed stream.
+     * (`getPendingToolInterrupts`/`streamWithEventsResume` absent) — that is the only exemption.
+     * As of EXT-52 BOTH backends gate `run_shell_command` and expose the interrupt surface, so the
+     * lean (default) agent is now exactly the agent this loop serves; only an agent implementation
+     * without those methods (e.g. a test double) skips it. Aborts (`signal`) propagate through the
+     * resumed stream.
      */
     async *resolveToolInterruptsWithEvents(signal) {
         const agent = this.agent;