fix(session): settle an approved call whose tool started as interrupted

A decision handed to the agent was tracked for the rebuild settle whether
or not its tool had started. The store shows a started call parked until
its result is saved, the same as one the closing reactor never ran, so an
interrupt that rebuilt in that window rejected the approved call as
dropped. The tool may already have run, the transcript said it was
denied, and the model could retry it.

The TUI now reports each tool.start to the approval resume, which watches
the calls it offered a decision for. A call whose tool started is
answered with a result that says the operator approved it and that it
may have completed, so the model checks before retrying. A call whose
tool never started is still rejected as dropped.

Author: bwachman

docs/ARCHITECTURE.md

@@ -411,7 +411,7 @@ tool call
 - **command** — Splits chained commands for security classification and derives command-shape approval scopes. Multi-segment chains only offer an exact-command persist pattern (a prefix like `npm *` must not cover `npm i && rm -rf /` later).
 - **auto-shell-policy** — Constrains `run_shell` even when auto mode would otherwise rubber-stamp it. Before matching, `expandShellSubjects` peels `bash`/`sh`/`zsh -c`, `xargs` utility tails, and transparent prefixes (`env`, `nice`, `timeout`, …) so rules see the real payload; an unparseable wrapper (variable expansion or command substitution) sets an opaque flag that forces `ask`. Effects: `deny` blocks outright (file mutations through ad-hoc tooling — output redirection, `tee`, `sed -i`/`perl -i`, interpreter inline programs or heredocs — which must instead go through `write_file`/`edit_file`); `ask` declines to auto-allow and falls through to the operator prompt (recursive `rm`, dependency installs and remote runners: npm/yarn/pnpm/bun, pip, cargo, go, brew, npx/bunx, …, force or uncontained `git worktree` ops, shell that references a sensitive path such as `.env` or a private key, and opaque wrappers). Contained non-force `git worktree add`/`remove`/`prune` and read-only `list` auto-allow (sibling destinations like `../corbits-dispatch-wts/…` included; absolute outside, `~`, globs, and credential basenames still ask). Deny beats ask when multiple subjects match. Quoted spans are stripped before pattern matching so a quoted `>` or install word in an argument is not flagged, and program names are matched only in command position. Adding a table category is a one-line rule append in `AUTO_SHELL_RULES`.
 - **gate** — Evaluates a call in order: catastrophic authorization denial, `skipPermissions`, then the normal tier, grant, and auto policies. Catastrophic commands remain denied under every mode. Skip mode, enabled for the process by `--dangerously-skip-permissions` or `--yolo` and persisted to the active settings source by TUI `/yolo` (machine-wide only for the default user-global source, not an explicit `--config` source), allows the call before normal policy evaluation. Therefore `--auto --yolo` behaves as yolo: auto-mode file-mutation asks and denials do not run. Otherwise, `allow`-tier passes; for `ask`-tier, the gate checks persisted approvals and then requests operator approval. Shell security classifies each chain segment (`||` / `&&` / `|` / `;` / newlines), but the operator is prompted once for the full command block — any unapproved segment fails the whole block, and execution always runs the unsplit original. Safe pipeline tails and pure shell no-ops (`true` / `false` / `:` and bare control-flow keywords stranded by chain-splitting) skip without a prompt. In a non-interactive run an unresolved `ask` becomes a denial. In auto mode: non-shell built-ins in `AUTO_ALLOWED_TOOLS` (writes/edits/deletes, `web_fetch`, `web_search`, `manage_tasks`, `spawn_agent`, `wait_agents`, …) auto-allow when not path-restricted; for `run_shell` the gate consults the auto-shell policy — a `deny` rule fails the call, an `ask` rule skips the auto-allow shortcut and proceeds to the normal approval flow, and anything unmatched is auto-allowed. Paths outside the workspace on path-arg tools are denied at authorize time (the same sandbox path-escape enforces at execution, so the gate does not show an Accept overlay that cannot succeed). Writes under the in-workspace session state root (legacy `.agent-state`) still ask under auto mode. Under process-only `--dangerously-skip-permissions` / `--yolo` or TUI `/yolo` persisted in the active settings source (machine-wide only for the default user-global source), the gate auto-allows those same cases, and pre-gate sandboxes (path-escape, shell session cwd retention, `list_dir` / `delete_file` workspace bounds) honor `getSkipPermissions()` live so outside-workspace access is not hard-denied after the gate already allowed it — without rebuilding the plugin stack. Static secret-guard denies for path-keyed tools and authorization hard blocks still apply. Sensitive shell references require approval in normal and auto modes, but skip mode allows them without approval after catastrophic authorization checks. Mutating MCP and unknown built-ins are not blanket-allowed outside skip. Newly granted scopes are appended in memory and persisted.
-  - **Reactor-gated sessions (main session; `reactorGated: true`).** The gate's decision logic lives in one `decide()` used by both consumers: `evaluate()` (the middleware path below, still used by sub-agents) and `authorizeCall()`, which expresses the decision as the vendored reactor's before-tool authz effect (`src/permission/reactor-authorize.ts` bridges it into `env.authorize`). An `ask` there suspends the call as a reactor `PendingOperation` keyed by a correlationId (persisted through the context store's existing `pendingOperations`); `send()` settles as `suspended` and `src/session/approval-resume.ts` rebuilds the operator request from the approval snapshot, resolves it through the same `requestApproval` seam the TUI overlay uses, and delivers the decision to the reactor on the correlationId signal channel — an approved decision grants a one-shot bypass and the exact parked call re-dispatches; a rejected one answers it with an error result. Idle rebuild waits on three signals. `inFlight` occupancy keeps the TUI busy across the overlay until the correlated resume is accepted (`message.received` / `message.correlated`) or a generation bump `settleAll`s the waiter. The reactor's message-run bracket (`message.run.started` to `message.run.ended`) stays open while the parked run suspends and while the resumed tool and next inference execute, so a deferred reload (for example, MCP tools landing while the overlay is up) runs only after the run reaches `reply`, `wait`, or `done`. A decision delivered to a reactor that rehydrated the parked approval from disk resumes with no run open, so the TUI also holds rebuilds from that `message.correlated` until the reactor announces a terminal (`connector.reply`, a run end, the chat director's silent settle of a dropped approval, a fatal `reactor.error`, or `reactor.done`). Every agent build logs its reason (`initial`, `mcp-tools-changed`, `interrupt`, `session-rotation`). Delivery generation owns session identity: interrupt, `/clear`, and `/new` abort the outstanding overlay, skip minting a grant, drop the decision, and surface an operator notice rather than delivering the operator's decision into a rebuilt agent. A rebuild that keeps the session (interrupt, or an MCP tool-set reload) instead rejects each dropped approval its store still shows parked on the rebuilt agent, again on every such rebuild until the store shows the call closed, and the chat director commits that result without starting a turn. An operator decision handed to a reactor that closes before acting on it, or whose delivery fails or never sees its acceptance, leaves its call parked the same way and is settled the same way. `/clear` and `/new` forget dropped approvals, since the new session never loads the old one's parked calls. Under reactor gating the middleware/MCP `gateToolCall` is an execution backstop, not a second copy of `env.authorize`: it consumes the `authorizeCall` verdict only when id, name, and arguments match, and does not re-decide. Deny still blocks and does not call `next`; an `ask` or `allow` skips the middleware prompt so an approved re-dispatch never re-asks. A reused `codex-proxy` id cannot apply an outer `shell` allow to an inner `run_shell` deny. Inner posix runs whose outer tool is not `run_shell` (Codex `apply_patch` proxy) never pass `env.authorize`, so `gateToolCall` decides on that cache miss and still blocks a deny. The headless denial and the stricter chained-command hard-deny are preserved as deny effects (upstream `block`s) decided inside the same `decide()`.
+  - **Reactor-gated sessions (main session; `reactorGated: true`).** The gate's decision logic lives in one `decide()` used by both consumers: `evaluate()` (the middleware path below, still used by sub-agents) and `authorizeCall()`, which expresses the decision as the vendored reactor's before-tool authz effect (`src/permission/reactor-authorize.ts` bridges it into `env.authorize`). An `ask` there suspends the call as a reactor `PendingOperation` keyed by a correlationId (persisted through the context store's existing `pendingOperations`); `send()` settles as `suspended` and `src/session/approval-resume.ts` rebuilds the operator request from the approval snapshot, resolves it through the same `requestApproval` seam the TUI overlay uses, and delivers the decision to the reactor on the correlationId signal channel — an approved decision grants a one-shot bypass and the exact parked call re-dispatches; a rejected one answers it with an error result. Idle rebuild waits on three signals. `inFlight` occupancy keeps the TUI busy across the overlay until the correlated resume is accepted (`message.received` / `message.correlated`) or a generation bump `settleAll`s the waiter. The reactor's message-run bracket (`message.run.started` to `message.run.ended`) stays open while the parked run suspends and while the resumed tool and next inference execute, so a deferred reload (for example, MCP tools landing while the overlay is up) runs only after the run reaches `reply`, `wait`, or `done`. A decision delivered to a reactor that rehydrated the parked approval from disk resumes with no run open, so the TUI also holds rebuilds from that `message.correlated` until the reactor announces a terminal (`connector.reply`, a run end, the chat director's silent settle of a dropped approval, a fatal `reactor.error`, or `reactor.done`). Every agent build logs its reason (`initial`, `mcp-tools-changed`, `interrupt`, `session-rotation`). Delivery generation owns session identity: interrupt, `/clear`, and `/new` abort the outstanding overlay, skip minting a grant, drop the decision, and surface an operator notice rather than delivering the operator's decision into a rebuilt agent. A rebuild that keeps the session (interrupt, or an MCP tool-set reload) instead rejects each dropped approval its store still shows parked on the rebuilt agent, again on every such rebuild until the store shows the call closed, and the chat director commits that result without starting a turn. An operator decision handed to a reactor that closes before acting on it, or whose delivery fails or never sees its acceptance, leaves its call parked the same way and is settled the same way, except that an approved call whose tool had started (the TUI reports each `tool.start` to the resume) is answered as interrupted, not dropped, because it may have run and the model should check before retrying. `/clear` and `/new` forget dropped approvals, since the new session never loads the old one's parked calls. Under reactor gating the middleware/MCP `gateToolCall` is an execution backstop, not a second copy of `env.authorize`: it consumes the `authorizeCall` verdict only when id, name, and arguments match, and does not re-decide. Deny still blocks and does not call `next`; an `ask` or `allow` skips the middleware prompt so an approved re-dispatch never re-asks. A reused `codex-proxy` id cannot apply an outer `shell` allow to an inner `run_shell` deny. Inner posix runs whose outer tool is not `run_shell` (Codex `apply_patch` proxy) never pass `env.authorize`, so `gateToolCall` decides on that cache miss and still blocks a deny. The headless denial and the stricter chained-command hard-deny are preserved as deny effects (upstream `block`s) decided inside the same `decide()`.
   - **Approval resume identity.** Before opening the operator gate, resume captures the session generation and agent/store pair and resolves the correlation exactly once through `ContextStore.load().pendingOperations` to one approval operation's `suspendedCall.id`. Missing or duplicate mappings produce no gate or delivery; store errors propagate with registration cleanup. Every decision path first checks captured history for an exact-call approval timeout, and operator decisions check again after the gate. While the overlay is open, resume watches history for that exact-call timeout and aborts the overlay signal so the gate auto-denies, occupancy (`inFlight`) unsticks, and no late decision is delivered. Identical tool names and arguments never establish identity. Cancellation during lookup cannot deliver a rejection. This suppresses observed exact timeouts, not all expired correlations: the reactor removes correlation state before the queued timeout result publishes, and expiration can also race the final history check or TUI delivery queue. Atomic stale-decision admission remains reactor-owned work tracked separately in CL-8000.
   - **Worker reactor ownership.** `workerPermissionGate` is a reactor-gated view over the parent's live permission gate: grants and policy are shared, not copied or toggled. Worker posix plugins and inherited MCP tools are bound to that view at worker start, so they take the reactor-gated `gateToolCall` path because the view reports `isReactorGated()` — they do not close over the parent's middleware-gated `isReactorGated()`. Deny still blocks; ask/allow skip the middleware prompt. `authorizeCall` on the view never emits `ask` — unresolved approvals become denials that name the permission subject, without invoking an approval callback or suspending, even with an interactive parent; the parent can obtain a grant and retry. Worker control-plane tools (`submit_result`, `ask_director`, and nested fleet verbs other than `spawn_agent`) allow without a parent grant. Authorization and tool execution run under the same async-local worker identity and cwd. Fleet authority remains an independent restriction, not an alternative permission grant.
 

e2e/reactor-approval-reload.test.ts

@@ -17,6 +17,7 @@ import { createPermissionGate } from "../src/permission/gate.js";
 import { createReactorAuthorize } from "../src/permission/reactor-authorize.js";
 import {
   APPROVAL_DROPPED_NOTICE,
+  APPROVAL_INTERRUPTED_NOTICE,
   createApprovalResume,
   resolveParkedCallIdFromStore,
   type ApprovalResume,
@@ -73,6 +74,23 @@ function linearClient(calls: Record<string, unknown>[]): MCPClient {
   };
 }
 
+/** A save that stays in flight until released, whatever the abort signal. */
+function stuckLinearClient(calls: Record<string, unknown>[]) {
+  let release: (() => void) | undefined;
+  const released = new Promise<void>((resolve) => {
+    release = resolve;
+  });
+  const client: MCPClient = {
+    ...linearClient(calls),
+    async callResult(_toolName, args) {
+      calls.push(args);
+      await released;
+      return { blocks: [{ type: "text", text: "SAVED-1" }], isError: false };
+    },
+  };
+  return { client, release: () => release?.() };
+}
+
 function labelClient(): MCPClient {
   return {
     serverName: "linear",
@@ -451,7 +469,9 @@ type InterruptPoint =
    * After an approval reached a busy loop but the deliverer gave up waiting
    * to observe its acceptance.
    */
-  | "acceptance-timed-out";
+  | "acceptance-timed-out"
+  /** After an approved call's tool started, before its result is saved. */
+  | "tool-running";
 
 /**
  * Parks `call` on an ask, then interrupts at `opts.interruptWhile` (while
@@ -470,6 +490,7 @@ async function dropThenInterrupt(
      */
     deadlinePassesDuringRebuild?: boolean;
     interruptWhile?: InterruptPoint;
+    prepare?: (session: IntegrationSession) => Promise<void>;
   } = {},
 ): Promise<Dropped> {
   const interruptWhile = opts.interruptWhile ?? "resolving-call";
@@ -487,7 +508,11 @@ async function dropThenInterrupt(
     events: parkedEvents,
     callId,
     deadline,
-  } = await parkOnAsk(call, { adapter, droppedApprovalCalls: droppedCalls });
+  } = await parkOnAsk(call, {
+    adapter,
+    droppedApprovalCalls: droppedCalls,
+    ...(opts.prepare !== undefined ? { prepare: opts.prepare } : {}),
+  });
   const parkedCancel = { fn: undefined as (() => void) | undefined };
   const generation = createDeliveryGeneration(() => parkedCancel.fn?.());
   let releaseCallId: (() => void) | undefined;
@@ -532,6 +557,12 @@ async function dropThenInterrupt(
     }),
   });
   claimFrom = resume;
+  // As the TUI's stream sink does for every event it sees.
+  void (async () => {
+    for await (const event of live.session.agent.stream()) {
+      if (event.type === "tool.start") resume.toolStarted(event.data.call.id);
+    }
+  })().catch(() => undefined);
   const handling = resume.handle(suspended);
 
   let releaseBusy: (() => void) | undefined;
@@ -550,6 +581,14 @@ async function dropThenInterrupt(
     ctx.approve();
     await queued;
   }
+  if (interruptWhile === "tool-running") {
+    ctx.approve();
+    expect(await handling).toBe(true);
+    await waitFor(
+      () => parkedEvents.some((e) => e.type === "tool.start"),
+      "tool start",
+    );
+  }
   if (
     interruptWhile === "decision-accepted" ||
     interruptWhile === "acceptance-timed-out"
@@ -1160,6 +1199,39 @@ describe("integration: an ask dropped by an interrupt, then settled on the rebui
     20_000,
   );
 
+  test.serial(
+    "an approved call whose tool is still running is not rejected as dropped",
+    async () => {
+      const calls: Record<string, unknown>[] = [];
+      const stuck = stuckLinearClient(calls);
+      cleanups.push(() => stuck.release());
+      const reloaded = await dropThenInterrupt(
+        { name: SAVE_ISSUE, args: { title: "in flight" } },
+        NATIVE_ANTHROPIC,
+        {
+          interruptWhile: "tool-running",
+          prepare: async (session) => {
+            session.toolset.dynamicRunner.addTools(
+              mcpClientTools(stuck.client),
+            );
+            await session.rebuild();
+          },
+        },
+      );
+      const { session, callId, parkedEvents } = reloaded;
+
+      expect(calls).toEqual([{ title: "in flight" }]);
+      expect(parkedEvents.filter((e) => e.type === "tool.start")).toHaveLength(
+        1,
+      );
+      const settled = toolResultsFor(await session.agent.history(), callId);
+      expect(settled).toHaveLength(1);
+      expect(settled.join("")).not.toContain(APPROVAL_DROPPED_NOTICE);
+      expect(settled.join("")).toContain(APPROVAL_INTERRUPTED_NOTICE);
+    },
+    20_000,
+  );
+
   test.serial(
     "an approval whose acceptance was never observed settles with no model turn",
     async () => {