@gotgenes/pi-permission-system 31.1.4 → 32.0.1

package/CHANGELOG.md

@@ -5,6 +5,29 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [32.0.1](https://github.com/gotgenes/pi-packages/compare/pi-permission-system-v32.0.0...pi-permission-system-v32.0.1) (2026-09-11)
+
+
+### Bug Fixes
+
+* **pi-permission-system:** deny a forbidden command without prompting first ([b840196](https://github.com/gotgenes/pi-packages/commit/b8401962a9eeb012317771fc204c3fde8aa8a9a2)), closes [#899](https://github.com/gotgenes/pi-packages/issues/899)
+
+### Documentation
+
+* **pi-permission-system:** document that a deny on any layer needs no prompt ([e526e95](https://github.com/gotgenes/pi-packages/commit/e526e950ab6d957e6b5bc4d6f7740bcce2e35dca)), closes [#899](https://github.com/gotgenes/pi-packages/issues/899)
+
+## [32.0.0](https://github.com/gotgenes/pi-packages/compare/pi-permission-system-v31.1.4...pi-permission-system-v32.0.0) (2026-09-11)
+
+
+### Features
+
+* **pi-permission-system:** **breaking:** prompt in the parent session for a subagent that has its own UI ([24b56a2](https://github.com/gotgenes/pi-packages/commit/24b56a2181df3db8b17e45b1acefd5a53fe2eddf)), closes [#907](https://github.com/gotgenes/pi-packages/issues/907), closes [#909](https://github.com/gotgenes/pi-packages/issues/909)
+* **pi-permission-system:** record when a session starts or stops relaying its asks ([7d1e2bb](https://github.com/gotgenes/pi-packages/commit/7d1e2bbe69d59360a66a27d3277d41aedecbefb5)), closes [#909](https://github.com/gotgenes/pi-packages/issues/909)
+
+### Documentation
+
+* **pi-permission-system:** document relaying from a session that has its own UI ([0250d68](https://github.com/gotgenes/pi-packages/commit/0250d68bb3a89e32782836ed1b6a17d4e52d25e8)), closes [#909](https://github.com/gotgenes/pi-packages/issues/909)
+
 ## [31.1.4](https://github.com/gotgenes/pi-packages/compare/pi-permission-system-v31.1.3...pi-permission-system-v31.1.4) (2026-09-11)
 
 

package/README.md

@@ -97,6 +97,7 @@ The trailing `*` is greedy and crosses subdirectory boundaries, so it allows eve
 
 Four layers compose with most-restrictive-wins: `path` (cross-cutting) → `external_directory` (CWD boundary) → per-tool patterns → `bash` command patterns.
 Because `ask` is more restrictive than `allow`, a `path` allow cannot loosen an `external_directory: ask` boundary — allow outside-CWD directories on `external_directory`.
+And because `deny` is more restrictive than `ask`, a `deny` on any layer refuses the call without prompting, naming the rule that decided.
 See [docs/configuration.md](docs/configuration.md) for the full recipe.
 
 Both path surfaces also carry a **direction**, so you can permit reading somewhere without permitting writing there: `path_read`, `path_write`, `external_directory_read`, and `external_directory_write`.

package/docs/configuration.md

@@ -559,6 +559,10 @@ Use `path` to **deny** sensitive files everywhere (`.env`, `~/.ssh/*`); use `ext
 Because the layers compose with most-restrictive-wins, a `path` allow cannot loosen an `external_directory: ask` boundary — `ask` is more restrictive than `allow`, so the prompt still fires.
 Adding `"~/.cargo/registry": "allow"` to the `path` surface therefore does **not** stop the outside-CWD prompt; put the rule on `external_directory` instead (see below).
 
+The same ordering runs the other way at the top of the scale.
+`deny` is more restrictive than `ask`, so a `deny` on any layer refuses the call **without prompting**, whichever layer carries the rule.
+A `bash: {"find / *": "deny"}` rule therefore suppresses the outside-CWD prompt that `find /` would otherwise raise, and the refusal names the `bash` rule that decided rather than the boundary that asked.
+
 Configs without a `path` key behave identically to before — the gate does not fire.
 When no `path` key is present, the universal fallback (`permission["*"]`) applies: `"*": "allow"` keeps the gate transparent, while `"*": "deny"` would deny all file access via every surface including `path`.
 

package/docs/subagent-integration.md

@@ -63,6 +63,19 @@ A value naming the reading session itself is ignored as a forwarding target, sin
 That matters when an implementation rewrites an inherited marker with the current session's id: doing so in a child destroys the only record of its real parent, and the child's asks then fail closed with an unresolved-target error.
 Guard such a rewrite on the process being a root — for example, skip it when a child marker such as `PI_SUBAGENT_CHILD` is present.
 
+#### Children that keep a UI of their own
+
+An implementation may spawn each child as a full interactive session — a visible pane per agent, for observability and direct inspection — while keeping permission authority with the human at the lead session.
+A child like that forwards its asks to the session the variable names, rather than opening its own dialog, for as long as that session is draining its forwarded-permission inbox.
+It is the declared target that decides this, so an implementation opts in by naming a parent, and opts out by not naming one; nothing else is required of it.
+
+The liveness condition is what keeps a visible child usable.
+A child whose named parent has exited, been killed, or stopped polling opens its own dialog instead of refusing the tool call, and the decision is remade on every turn: a pane whose lead exits mid-run returns to prompting locally at its next turn, and one whose lead comes back starts forwarding again.
+Only an ask already in flight when the parent disappears is refused, with the usual approval-unavailable reason.
+
+A session that relays still serves its own inbox, so a `lead → agent → agent` tree relays through the middle hop.
+What it does not do is run its own authorizer chain: live authority converges at the node that decides, which is the serving one ([ADR 0007] §7).
+
 ### What an implementation does not owe
 
 None of the following is an implementation's responsibility, on either process shape:
@@ -132,7 +145,7 @@ When `@gotgenes/pi-permission-system` is not installed, an implementation emits
 
 ## Permission Forwarding
 
-When a delegated or routed subagent runs without direct UI access, `ask` permissions can still be enforced by forwarding the confirmation request through Pi session directories.
+When a delegated or routed subagent cannot decide an `ask` where it runs — because it has no UI of its own, or because it names a parent session that is answering for it — the confirmation request is forwarded through Pi session directories instead.
 The main interactive session polls for forwarded requests, shows the confirmation prompt, writes the response, and the subagent resumes once that decision is available.
 A parent `allow`/`deny` rule governs a child's escalation directly (the serving node resolves it as recorded authority before prompting), and a "whole session" grant recorded on the parent auto-approves later forwards of the same pattern.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gotgenes/pi-permission-system",
-  "version": "31.1.4",
+  "version": "32.0.1",
   "description": "Permission enforcement extension for the Pi coding agent.",
   "type": "module",
   "exports": {

package/src/authority/approval-escalator.ts

@@ -173,10 +173,11 @@ function forwardableRequestId(requesterRequestId: string): string {
  * Owns the escalation-up role of the forwarded-permission behavior: builds
  * and persists a request file, then polls for the parent session's
  * response. `ctx` is bound once at construction — `selectAuthorizer` only
- * constructs a `ParentAuthorizer` for a context it has already confirmed has
- * no UI and is a subagent, so `authorize` never re-derives that dispatch
- * (formerly `ApprovalEscalator.requestApproval`'s `hasUI` / `!isSubagent`
- * arms, both dead once every caller routes through `selectAuthorizer`).
+ * constructs a `ParentAuthorizer` for a context it has already established is a
+ * child, whether that child has a UI of its own (#909) or not, so `authorize`
+ * never re-derives that dispatch (formerly `ApprovalEscalator.requestApproval`'s
+ * `hasUI` / `!isSubagent` arms, both dead once every caller routes through
+ * `selectAuthorizer`).
  */
 export class ParentAuthorizer implements TerminalAuthorizer {
   private readonly forwardingDir: string;
@@ -221,10 +222,9 @@ export class ParentAuthorizer implements TerminalAuthorizer {
   ): Promise<PermissionPromptDecision> {
     const requesterSessionId = getSessionId(ctx);
     const target = resolvePermissionForwardingTarget({
-      hasUI: ctx.hasUI,
-      // Invariant: selectAuthorizer only selects ParentAuthorizer for a
-      // no-UI subagent context, so this is always true — no detection dep
-      // needed to re-derive it here.
+      // Invariant: selectAuthorizer only selects ParentAuthorizer for a context
+      // it has already established is a child — no detection dep needed to
+      // re-derive it here.
       isSubagent: true,
       currentSessionId: requesterSessionId,
       env: process.env,

package/src/authority/authorizer-selection.ts

@@ -10,6 +10,7 @@ import { composeAuthorizerChain } from "./authorizer-chain";
 import type { AuthorizerLookup } from "./authorizer-registry";
 import { encloseInDelegationEnvelope } from "./delegation-envelope";
 import type { PermissionPromptDecision } from "./permission-dialog";
+import type { PermissionForwardingTarget } from "./permission-forwarding";
 import type {
   PermissionPrompterApi,
   PromptPermissionDetails,
@@ -48,9 +49,13 @@ export interface AskEscalator {
  * so a sibling extension learns it without knowing what a subagent is) and by
  * the registration observer (which records a link registered where no chain
  * runs). Both depend on this single-method view rather than the selection
- * itself, and neither may re-derive the role from `detection.isSubagent(ctx)`:
- * `selectAuthorizer` tests `hasUI` first, so a subagent with its own UI
- * adjudicates locally.
+ * itself, and neither may re-derive the role from `ctx.hasUI` or
+ * `detection.isSubagent(ctx)`: a node with a UI relays when it names another
+ * session that is draining its inbox, and decides locally otherwise (#909).
+ *
+ * Because the selection is remade on every activation, the answer can change
+ * within one session — a node stops relaying as soon as its declared parent
+ * stops serving.
  */
 export interface AdjudicationRole {
   adjudicatesLocally(): boolean;
@@ -72,6 +77,7 @@ export class AuthorizerSelection
   implements AskEscalator, AuthorizerSelectionLifecycle, AdjudicationRole
 {
   private authority: SelectedAuthority | null = null;
+  private relayTarget: PermissionForwardingTarget | null = null;
 
   constructor(
     private readonly deps: AuthorizerSelectionDeps & {
@@ -92,7 +98,39 @@ export class AuthorizerSelection
    * activation, so link resolution is deferred to the session's first ask.
    */
   activate(ctx: ExtensionContext): void {
-    this.authority = selectAuthorizer(ctx, this.deps);
+    const authority = selectAuthorizer(ctx, this.deps);
+    this.recordRelayTransition(authority.relayTarget ?? null);
+    this.authority = authority;
+  }
+
+  /**
+   * Record that this node started, stopped, or redirected its relaying.
+   *
+   * `activate` runs on every turn event, so only a change is worth a line: the
+   * pair reads beside the serving node's own
+   * `forwarded_permission.serving_started`/`serving_stopped`, which is what
+   * makes a misdirected relay a one-line diff across the two sessions. A node
+   * that never relays writes nothing at all.
+   */
+  private recordRelayTransition(
+    target: PermissionForwardingTarget | null,
+  ): void {
+    const previous = this.relayTarget;
+    if (previous?.sessionId === target?.sessionId) {
+      return;
+    }
+    this.relayTarget = target;
+    if (previous !== null) {
+      this.deps.logger.review("forwarded_permission.relay_stopped", {
+        targetSessionId: previous.sessionId,
+      });
+    }
+    if (target !== null) {
+      this.deps.logger.review("forwarded_permission.relay_started", {
+        targetSessionId: target.sessionId,
+        channel: target.source,
+      });
+    }
   }
 
   /**
@@ -181,6 +219,7 @@ export class AuthorizerSelection
 
   /** Clear the stored selection. */
   deactivate(): void {
+    this.recordRelayTransition(null);
     this.authority = null;
   }
 

package/src/authority/authorizer.ts

@@ -4,9 +4,12 @@ import type { AuthorizerLog, PermissionQuery } from "#src/service";
 import type { PermissionEventBus } from "#src/service/permission-events";
 import { ParentAuthorizer } from "./approval-escalator";
 import { DenyingAuthorizer } from "./denying-authorizer";
+import { getSessionId } from "./forwarder-context";
 import type { TargetServingLookup } from "./forwarding-liveness";
 import { LocalUserAuthorizer } from "./local-user-authorizer";
 import type { PermissionPromptDecision } from "./permission-dialog";
+import type { PermissionForwardingTarget } from "./permission-forwarding";
+import { resolvePermissionForwardingTarget } from "./permission-forwarding";
 import type {
   PromptPreferences,
   requestPermissionDecision,
@@ -77,9 +80,10 @@ export interface TerminalAuthorizer {
  * whether this node adjudicates them with its own chain.
  *
  * The chain role is the selection's product, not a discriminator a consumer
- * re-derives: `selectAuthorizer` tests `hasUI` before `isSubagent`, so a
- * subagent that has its own UI decides locally, and re-deriving the role from
- * `detection.isSubagent(ctx)` alone would get that case wrong.
+ * re-derives: a node with a UI decides locally unless it names another session
+ * that is draining its forwarded-permission inbox (#909), so re-deriving the
+ * role from `ctx.hasUI` or `detection.isSubagent(ctx)` alone would get that
+ * case wrong in opposite directions.
  */
 export interface SelectedAuthority {
   /** The terminal that decides this node's asks, or relays them upward. */
@@ -92,6 +96,12 @@ export interface SelectedAuthority {
    * twice.
    */
   readonly adjudicatesLocally: boolean;
+  /**
+   * The target this selection itself verified as live, for the relay-transition
+   * record. Absent on the headless relay arm, where the target is resolved per
+   * ask by `ParentAuthorizer` rather than at selection.
+   */
+  readonly relayTarget?: PermissionForwardingTarget;
 }
 
 /** Construction inputs for {@link selectAuthorizer}. */
@@ -117,40 +127,84 @@ export interface AuthorizerSelectionDeps {
 
 /**
  * Select the live authority for the current context: the single owner of the
- * three-way `hasUI` / `isSubagent` / deny dispatch, and of the chain role that
- * dispatch implies.
+ * three-way local / relay / deny dispatch, and of the chain role that dispatch
+ * implies.
  *
- * Evaluated once per session activation (`AuthorizerSelection.activate`),
- * replacing the re-derivation of the same predicates across
- * `PromptingGateway`, `PermissionPrompter`, and `ApprovalEscalator`.
+ * Evaluated on every session activation (`AuthorizerSelection.activate`), which
+ * is what lets a node with a UI follow its declared parent's liveness: the
+ * moment that parent stops serving, the next activation selects the local
+ * dialog again.
  */
 export function selectAuthorizer(
   ctx: ExtensionContext,
   deps: AuthorizerSelectionDeps,
 ): SelectedAuthority {
   if (ctx.hasUI) {
+    const relayTarget = resolveLiveRelayTarget(ctx, deps);
+    if (relayTarget === null) {
+      return {
+        terminal: new LocalUserAuthorizer({
+          ui: ctx.ui,
+          mode: ctx.mode,
+          events: deps.events,
+          getPromptPreferences: deps.getPromptPreferences,
+          requestPermissionDecision: deps.requestPermissionDecision,
+        }),
+        adjudicatesLocally: true,
+      };
+    }
     return {
-      terminal: new LocalUserAuthorizer({
-        ui: ctx.ui,
-        mode: ctx.mode,
-        events: deps.events,
-        getPromptPreferences: deps.getPromptPreferences,
-        requestPermissionDecision: deps.requestPermissionDecision,
-      }),
-      adjudicatesLocally: true,
+      terminal: buildParentAuthorizer(ctx, deps),
+      adjudicatesLocally: false,
+      relayTarget,
     };
   }
   if (deps.detection.isSubagent(ctx)) {
     return {
-      terminal: new ParentAuthorizer(ctx, {
-        forwardingDir: deps.forwardingDir,
-        registry: deps.registry,
-        serving: deps.serving,
-        getTimeoutMs: deps.getForwardingTimeoutMs,
-        logger: deps.logger,
-      }),
+      terminal: buildParentAuthorizer(ctx, deps),
       adjudicatesLocally: false,
     };
   }
   return { terminal: new DenyingAuthorizer(), adjudicatesLocally: true };
 }
+
+/**
+ * The session a node with a UI should relay to, or `null` when it should decide
+ * for itself.
+ *
+ * A human is present here, so only a definite "yes" relays: a target nobody can
+ * confirm is draining its inbox leaves the ask with the human who is already
+ * watching. That is the opposite burden of proof from
+ * `ParentAuthorizer.checkServingLiveness`, where an unjudgeable target waits
+ * out the timeout because a headless child has no alternative.
+ */
+function resolveLiveRelayTarget(
+  ctx: ExtensionContext,
+  deps: AuthorizerSelectionDeps,
+): PermissionForwardingTarget | null {
+  const sessionId = getSessionId(ctx);
+  const target = resolvePermissionForwardingTarget({
+    isSubagent: deps.detection.isSubagent(ctx),
+    currentSessionId: sessionId,
+    sessionId,
+    registry: deps.registry,
+  });
+  if (target === null || deps.serving.isServing(target) !== true) {
+    return null;
+  }
+  return target;
+}
+
+/** The relaying terminal for `ctx`, built from the selection's own deps. */
+function buildParentAuthorizer(
+  ctx: ExtensionContext,
+  deps: AuthorizerSelectionDeps,
+): ParentAuthorizer {
+  return new ParentAuthorizer(ctx, {
+    forwardingDir: deps.forwardingDir,
+    registry: deps.registry,
+    serving: deps.serving,
+    getTimeoutMs: deps.getForwardingTimeoutMs,
+    logger: deps.logger,
+  });
+}

package/src/authority/forwarding-liveness.ts

@@ -92,8 +92,7 @@ export interface HeartbeatReader {
  * Keyed on the target rather than a session id because the answer depends on
  * how the target was resolved. An in-process child and its parent share a
  * `globalThis`, so the registry answers for them; an out-of-process pair shares
- * only the filesystem; and a session that owns the inbox it is forwarding to is
- * not a case either channel describes.
+ * only the filesystem.
  *
  * Consolidating that into one collaborator is what keeps `ParentAuthorizer`
  * from holding two lookups and re-deciding which one applies — the decision has
@@ -108,6 +107,10 @@ export interface TargetServingLookup {
 
 /** What answered a liveness question, and what it saw. */
 export interface ServingObservation {
+  /**
+   * Which channel answered. `"none"` belongs to a lookup that consulted none —
+   * the real judge never gives it, since every target it sees names a channel.
+   */
   channel: "registry" | "heartbeat" | "none";
   /** The heartbeat state behind a `"heartbeat"` answer; `null` on the other channels. */
   state: HeartbeatState | null;
@@ -138,8 +141,6 @@ export class ForwardingLivenessJudge implements TargetServingLookup {
         return this.deps.registry.isServing(target.sessionId);
       case "env":
         return this.deps.heartbeats.read(target.sessionId) === "alive";
-      case "self":
-        return null;
     }
   }
 
@@ -157,8 +158,6 @@ export class ForwardingLivenessJudge implements TargetServingLookup {
           state: this.deps.heartbeats.read(target.sessionId),
           servingIds: this.deps.heartbeats.servingIds(),
         };
-      case "self":
-        return { channel: "none", state: null, servingIds: [] };
     }
   }
 }

package/src/authority/permission-forwarding.ts

@@ -287,10 +287,9 @@ export function createPermissionForwardingLocation(
  * **in-process** child of `sessionId`, so the two share a `globalThis` and the
  * requester may consult the serving-session registry to decide whether anyone
  * is draining its inbox. `"env"` means the target lives in another process,
- * where that signal is unavailable; `"self"` is the UI host owning its own
- * forwarding location.
+ * where that signal is unavailable.
  */
-export type PermissionForwardingTargetSource = "self" | "registry" | "env";
+export type PermissionForwardingTargetSource = "registry" | "env";
 
 /** The resolved forwarding target together with how it was found. */
 export interface PermissionForwardingTarget {
@@ -298,8 +297,14 @@ export interface PermissionForwardingTarget {
   source: PermissionForwardingTargetSource;
 }
 
+/**
+ * The session this node relays its asks to, or `null` when it has none.
+ *
+ * Answers only "which *other* session", never "myself": a node that owns its
+ * forwarding location has nothing to resolve, and a request filed into one's
+ * own inbox is drained by no watcher.
+ */
 export function resolvePermissionForwardingTarget(options: {
-  hasUI: boolean;
   isSubagent: boolean;
   currentSessionId?: string | null;
   env?: NodeJS.ProcessEnv;
@@ -308,13 +313,6 @@ export function resolvePermissionForwardingTarget(options: {
   /** In-process subagent session registry (checked before env vars). */
   registry?: SubagentSessionRegistry;
 }): PermissionForwardingTarget | null {
-  if (options.hasUI) {
-    const own = normalizePermissionForwardingSessionId(
-      options.currentSessionId,
-    );
-    return own === null ? null : { sessionId: own, source: "self" };
-  }
-
   if (!options.isSubagent) {
     return null;
   }

package/src/authority/subagent-detection.ts

@@ -15,9 +15,10 @@ import type { SubagentSessionRegistry } from "./subagent-registry";
  * It answers "is this process a child", which is **not** "should this node relay
  * rather than decide". A UI host answers `true` here whenever its process
  * carries a parent-session marker — a spawner may export one from the root so
- * the children it launches inherit it. Every consumer therefore tests `hasUI`
- * first: `selectAuthorizer` returns before reaching this predicate, and serving
- * eligibility does not consult it at all (#907).
+ * the children it launches inherit it. No consumer may read it as a relay
+ * decision: `selectAuthorizer` relays a node with a UI only when a forwarding
+ * target resolves *and* that target is serving (#909), and serving eligibility
+ * does not consult this predicate at all (#907).
  */
 export interface SubagentDetector {
   isSubagent(ctx: SubagentDetectionContext): boolean;

package/src/handlers/gates/descriptor.ts

@@ -97,6 +97,81 @@ export interface GateBypass {
 /** Union of possible gate function return values. */
 export type GateResult = GateDescriptor | GateBypass | null;
 
+// ── Resolved-state readers ─────────────────────────────────────────────────
+
+/**
+ * The permission check a descriptor already carries, or `null` when it
+ * resolves nothing of its own.
+ *
+ * Every tool-call gate resolves its own state before the runner sees it —
+ * five of the six stamp a full `preCheck`, and the skill-read gate stamps the
+ * `preResolved` state it read off the matched skill entry. This is the one
+ * place that precedence is expressed, so the runner and the pre-emption
+ * predicate cannot answer it differently.
+ *
+ * A `null` answer is not "allow": it means the caller must resolve the
+ * descriptor itself.
+ */
+export function preResolvedCheckOf(
+  descriptor: GateDescriptor,
+): PermissionCheckResult | null {
+  if (descriptor.preCheck) {
+    return descriptor.preCheck;
+  }
+  if (descriptor.preResolved) {
+    return {
+      state: descriptor.preResolved.state,
+      toolName: descriptor.surface,
+      source: "tool",
+      origin: "builtin",
+    };
+  }
+  return null;
+}
+
+/**
+ * Whether this gate blocks without escalating, whatever the other gates say.
+ *
+ * A `deny` is absorbing: wherever it sits in the pipeline's order, the call is
+ * refused, so no other gate's answer — and no human's — can change the
+ * outcome. That is what makes running it first an ordering change rather than
+ * a semantic one, and it is why the same treatment is *not* extended to `ask`
+ * (#915): two asking gates ask two different questions.
+ *
+ * Subordinate to {@link GateRunner.runDescriptor}'s own precedence, which
+ * tests `source === "session"` before the deny/ask/allow gate is reached — a
+ * session-sourced check is allowed there, so it is not pre-emptive here.
+ * `SessionRules` records only allows, so that combination is unreachable
+ * today; the clause is kept so the predicate is correct on its own terms
+ * rather than by way of a distant invariant, and it errs toward today's
+ * behavior by declining to pre-empt.
+ *
+ * Yolo needs no clause: `resolveYoloGrant` matches an `allow` of origin
+ * `yolo` and an `ask`, never a `deny`.
+ */
+export function isUnconditionalDeny(gate: GateResult): boolean {
+  if (!isGateDescriptor(gate)) {
+    return false;
+  }
+  const check = preResolvedCheckOf(gate);
+  return check !== null && check.state === "deny" && check.source !== "session";
+}
+
+/**
+ * The gates in run order, with any unconditional deny moved to the front.
+ *
+ * A stable partition, so two denying gates keep their relative order (the
+ * earlier one still decides, exactly as before) and the remainder keeps its
+ * own. With no deny present the array is returned unchanged.
+ */
+export function orderDenyFirst(gates: GateResult[]): GateResult[] {
+  const denying = gates.filter((gate) => isUnconditionalDeny(gate));
+  if (denying.length === 0) {
+    return gates;
+  }
+  return [...denying, ...gates.filter((gate) => !isUnconditionalDeny(gate))];
+}
+
 // ── Type guard helpers ─────────────────────────────────────────────────────
 
 /** Check whether a GateResult is a GateBypass (early allow). */

package/src/handlers/gates/runner.ts

@@ -12,13 +12,12 @@ import {
 } from "#src/presentation/agent-renderer";
 import { renderReviewLogFacts } from "#src/presentation/review-log-renderer";
 import type { SessionApprovalRecorder } from "#src/session/session-approval-recorder";
-import type { PermissionCheckResult } from "#src/types";
 import type {
   DecisionEventFacts,
   GateDescriptor,
   GateResult,
 } from "./descriptor";
-import { isGateBypass } from "./descriptor";
+import { isGateBypass, preResolvedCheckOf } from "./descriptor";
 import { buildDecisionEvent, resolveYoloGrant } from "./helpers";
 import type { GateOutcome } from "./types";
 
@@ -89,25 +88,16 @@ export class GateRunner {
     agentName: string | null,
     requestId: string,
   ): Promise<GateOutcome> {
-    // 1. Resolve permission state — pre-check, pre-resolved, or via resolver
-    let check: PermissionCheckResult;
-    if (descriptor.preCheck) {
-      check = descriptor.preCheck;
-    } else if (descriptor.preResolved) {
-      check = {
-        state: descriptor.preResolved.state,
-        toolName: descriptor.surface,
-        source: "tool",
-        origin: "builtin",
-      };
-    } else {
-      check = this.resolver.resolve({
+    // 1. Resolve permission state — what the descriptor already carries, or
+    // via the resolver when it carries nothing.
+    const check =
+      preResolvedCheckOf(descriptor) ??
+      this.resolver.resolve({
         kind: "tool",
         surface: descriptor.surface,
         input: descriptor.input,
         agentName: agentName ?? undefined,
       });
-    }
 
     // The fields every review-log write for this gate shares, whatever the
     // resolution — built once so a field added here reaches all of them. The

package/src/handlers/gates/tool-call-gate-pipeline.ts

@@ -18,7 +18,7 @@ import type { PermissionCheckResult } from "#src/types";
 import { resolveBashCommandCheck } from "./bash-command";
 import { describeBashExternalDirectoryGate } from "./bash-external-directory";
 import { describeBashPathGate } from "./bash-path";
-import type { GateResult } from "./descriptor";
+import { type GateResult, orderDenyFirst } from "./descriptor";
 import { describeExternalDirectoryGate } from "./external-directory";
 import { describePathGate } from "./path";
 import type { GateRunner } from "./runner";
@@ -62,7 +62,8 @@ export interface ToolCallGateInputs {
  * - `ToolPreviewFormatter` construction from `getToolPreviewLimits()`
  * - infrastructure-dir list from `getInfrastructureReadDirs()`
  * - all six gate producers in their prescribed order
- * - the run loop that returns the first block outcome, or allow
+ * - the run loop, which runs an unconditionally denying gate ahead of the
+ *   rest and returns the first block outcome, or allow
  */
 export class ToolCallGatePipeline {
   constructor(
@@ -141,8 +142,18 @@ export class ToolCallGatePipeline {
       },
     ];
 
+    // Produce every gate before running any of them, so an unconditional deny
+    // on a later gate is known before an earlier one suspends the call on an
+    // `ask` nobody's answer could change (#899). Producing is side-effect-free
+    // — all logging and event emission happens inside `runner.run` — and the
+    // loop below already produced every gate on any call it did not block.
+    const gates: GateResult[] = [];
     for (const produce of gateProducers) {
-      const outcome = await runner.run(await produce(), tcc.agentName);
+      gates.push(await produce());
+    }
+
+    for (const gate of orderDenyFirst(gates)) {
+      const outcome = await runner.run(gate, tcc.agentName);
       if (outcome.action === "block") {
         return outcome;
       }