agent-relay-runner 0.127.8 → 0.127.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-relay-runner",
-  "version": "0.127.8",
+  "version": "0.127.10",
   "description": "Unified provider lifecycle runner for Agent Relay",
   "type": "module",
   "bin": {
@@ -23,7 +23,7 @@
   },
   "dependencies": {
     "agent-relay-providers": "0.104.4",
-    "agent-relay-sdk": "0.2.121",
+    "agent-relay-sdk": "0.2.123",
     "callmux": "0.23.0"
   },
   "devDependencies": {

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agent-relay-runner",
   "description": "Thin Agent Relay runner bridge for Claude Code",
-  "version": "0.127.8",
+  "version": "0.127.10",
   "agentRelayContracts": {
     "providerPluginProtocol": 1
   }

package/plugins/claude/monitors/relay-monitor.provisioned.mjs

@@ -56,8 +56,8 @@ var RUNNER_PROMPT_TEMPLATE_DEFAULTS = [
     category: "runner",
     title: "Runner Workspace Lifecycle Note",
     description: "Lifecycle note injected by the runner for isolated workspaces.",
-    template: lines("[agent-relay] Isolated workspace: you are in a git worktree on branch {{branch}}, based on {{baseRef}} \u2014 NOT the main checkout. Other agents may work in parallel and land to {{baseRef}}, so {{baseRef}} will move under you. That is expected; don't fight it.", "Do NOT push this branch yourself \u2014 not with `git push`, not with `tl push` or any other push wrapper, and do not manually rebase or merge. A steward may be auto-rebasing this branch in the background; pushing concurrently races it and can leave the worktree mid-rebase. Just commit your work here. When the task is done, call `relay_task_deliver` with disposition `complete`, a summary, commits, and passing `typecheck` + `test` gates. Relay records the typed delivery on the Task, then rebases onto the latest {{baseRef}}, lands your work, and pushes for you.", "After `relay_task_deliver` accepts a complete delivery, the workspace status becomes `ready` \u2014 this is the NORMAL, healthy hand-off state, NOT an escalation or a stall. Relay auto-merges clean rebases roughly every 2 minutes; a steward agent is spawned (after a short delay) ONLY if it can't land deterministically, so seeing no steward means it's working, not stuck. Stop your turn after delivery and go idle; do NOT wait or poll the steward queue. Relay wakes you with `landed-success` when your branch lands and refreshes, or `landed-failure` if landing fatally fails. On success you'll be on a fresh rebased branch whose name gains a `--N` suffix \u2014 expected, keep working there. Never `cd` into the main checkout, and never merge/push/resolve conflicts yourself \u2014 Relay and the steward own all of that. `agent-relay workspace status` anytime shows your current state and the exact next step."),
-    defaultTemplate: lines("[agent-relay] Isolated workspace: you are in a git worktree on branch {{branch}}, based on {{baseRef}} \u2014 NOT the main checkout. Other agents may work in parallel and land to {{baseRef}}, so {{baseRef}} will move under you. That is expected; don't fight it.", "Do NOT push this branch yourself \u2014 not with `git push`, not with `tl push` or any other push wrapper, and do not manually rebase or merge. A steward may be auto-rebasing this branch in the background; pushing concurrently races it and can leave the worktree mid-rebase. Just commit your work here. When the task is done, call `relay_task_deliver` with disposition `complete`, a summary, commits, and passing `typecheck` + `test` gates. Relay records the typed delivery on the Task, then rebases onto the latest {{baseRef}}, lands your work, and pushes for you.", "After `relay_task_deliver` accepts a complete delivery, the workspace status becomes `ready` \u2014 this is the NORMAL, healthy hand-off state, NOT an escalation or a stall. Relay auto-merges clean rebases roughly every 2 minutes; a steward agent is spawned (after a short delay) ONLY if it can't land deterministically, so seeing no steward means it's working, not stuck. Stop your turn after delivery and go idle; do NOT wait or poll the steward queue. Relay wakes you with `landed-success` when your branch lands and refreshes, or `landed-failure` if landing fatally fails. On success you'll be on a fresh rebased branch whose name gains a `--N` suffix \u2014 expected, keep working there. Never `cd` into the main checkout, and never merge/push/resolve conflicts yourself \u2014 Relay and the steward own all of that. `agent-relay workspace status` anytime shows your current state and the exact next step."),
+    template: lines("[agent-relay] Isolated workspace: you are in a git worktree on branch {{branch}}, based on {{baseRef}} \u2014 NOT the main checkout. Other agents may work in parallel and land to {{baseRef}}, so {{baseRef}} will move under you. That is expected; don't fight it.", "Do NOT push this branch yourself \u2014 not with `git push`, not with `tl push` or any other push wrapper, and do not manually rebase or merge. A steward may be auto-rebasing this branch in the background; pushing concurrently races it and can leave the worktree mid-rebase. Just commit your work here. When the task is done, call `relay_task_deliver` with disposition `complete`, a summary, commits, and passing `typecheck` + `test` gates when the diff touches code/test/config paths. Relay records the typed delivery on the Task, skips code gates for empty/docs-only diffs, then rebases onto the latest {{baseRef}}, lands your work, and pushes for you.", "After `relay_task_deliver` accepts a complete delivery, the workspace status becomes `ready` \u2014 this is the NORMAL, healthy hand-off state, NOT an escalation or a stall. Relay auto-merges clean rebases roughly every 2 minutes; a steward agent is spawned (after a short delay) ONLY if it can't land deterministically, so seeing no steward means it's working, not stuck. Stop your turn after delivery and go idle; do NOT wait or poll the steward queue. Relay wakes you with `landed-success` when your branch lands and refreshes, or `landed-failure` if landing fatally fails. On success you'll be on a fresh rebased branch whose name gains a `--N` suffix \u2014 expected, keep working there. Never `cd` into the main checkout, and never merge/push/resolve conflicts yourself \u2014 Relay and the steward own all of that. `agent-relay workspace status` anytime shows your current state and the exact next step."),
+    defaultTemplate: lines("[agent-relay] Isolated workspace: you are in a git worktree on branch {{branch}}, based on {{baseRef}} \u2014 NOT the main checkout. Other agents may work in parallel and land to {{baseRef}}, so {{baseRef}} will move under you. That is expected; don't fight it.", "Do NOT push this branch yourself \u2014 not with `git push`, not with `tl push` or any other push wrapper, and do not manually rebase or merge. A steward may be auto-rebasing this branch in the background; pushing concurrently races it and can leave the worktree mid-rebase. Just commit your work here. When the task is done, call `relay_task_deliver` with disposition `complete`, a summary, commits, and passing `typecheck` + `test` gates when the diff touches code/test/config paths. Relay records the typed delivery on the Task, skips code gates for empty/docs-only diffs, then rebases onto the latest {{baseRef}}, lands your work, and pushes for you.", "After `relay_task_deliver` accepts a complete delivery, the workspace status becomes `ready` \u2014 this is the NORMAL, healthy hand-off state, NOT an escalation or a stall. Relay auto-merges clean rebases roughly every 2 minutes; a steward agent is spawned (after a short delay) ONLY if it can't land deterministically, so seeing no steward means it's working, not stuck. Stop your turn after delivery and go idle; do NOT wait or poll the steward queue. Relay wakes you with `landed-success` when your branch lands and refreshes, or `landed-failure` if landing fatally fails. On success you'll be on a fresh rebased branch whose name gains a `--N` suffix \u2014 expected, keep working there. Never `cd` into the main checkout, and never merge/push/resolve conflicts yourself \u2014 Relay and the steward own all of that. `agent-relay workspace status` anytime shows your current state and the exact next step."),
     variables: ["branch", "baseRef"]
   },
   {

package/src/control-server.ts

@@ -323,34 +323,19 @@ async function handlePermissionRequest(
   const toolInput = isRecord(body.tool_input) ? body.tool_input : undefined;
   const approvalId = crypto.randomUUID();
 
-  // #1173: a PreToolUse "questions" prompt (the provider's AskUserQuestion) used to block this hook
-  // response for up to ~15 minutes waiting on the human — which meant the turn's reasoning that
-  // led to the question stayed buffered in the provider's process (never flushed to the transcript
-  // JSONL) for exactly as long as the human took to answer, so the dashboard could only ever
-  // show the question AFTER the reasoning that motivated it. Denying the tool call immediately
-  // is the ordinary, already-supported "rejected tool call" hook contract: the provider persists the
-  // buffered turn + a rejected tool_result right away, on its own, same as any other denied tool
-  // — so the settle-poll harvest below (previously doomed to time out for this one case) now
-  // finds the freshly-flushed anchor within moments. The human's eventual answer is delivered
-  // afterward as a normal injected prompt (see the `.then` below), not as this hook's response.
   const probeView = handler.buildView(approvalId, body, true);
-  if (body.hook_event_name === "PreToolUse" && probeView.kind === "questions" && handler.buildAnswerInjectionPrompt) {
-    const response = Response.json(handler.buildHookResponse(
-      { approvalId, decision: "deny", reason: PENDING_QUESTION_DENY_REASON },
-      body,
-    ));
-    void awaitPermissionDecision({
+  const answerInput = permissionRequestQuestionAnswers(body);
+  if (body.hook_event_name === "PermissionRequest" && probeView.kind === "questions" && answerInput) {
+    return Response.json(handler.buildHookResponse({ approvalId, decision: "answer", answers: answerInput }, body));
+  }
+  if (
+    (body.hook_event_name === "PreToolUse" || body.hook_event_name === "PermissionRequest")
+    && probeView.kind === "questions"
+    && handler.buildAnswerInjectionPrompt
+  ) {
+    return holdQuestionWithImmediateDeny({
       options, pendingPermissionRequests, handler, approvalId, body, occurredAt, transcriptPath, toolName, toolInput,
-      blockedReason: "pendingQuestion",
-      recommendedAction: "Answer the question in Agent Relay.",
-      suppressResolvedStatus: true,
-    }).then(({ decision, view }) => {
-      const text = decision.decision === "answer" && decision.answers && Object.keys(decision.answers).length
-        ? handler.buildAnswerInjectionPrompt!(view, decision, body)
-        : pendingQuestionDismissalPrompt(decision);
-      return options.onAnswerInject?.({ approvalId, text });
-    }).catch(() => {});
-    return response;
+    });
   }
 
   const { decision } = await awaitPermissionDecision({
@@ -361,6 +346,51 @@ async function handlePermissionRequest(
   return Response.json(handler.buildHookResponse(decision, body));
 }
 
+function permissionRequestQuestionAnswers(body: Record<string, unknown>): Record<string, string> | undefined {
+  if (body.hook_event_name !== "PermissionRequest") return undefined;
+  const toolInput = isRecord(body.tool_input) ? body.tool_input : {};
+  if (!isRecord(toolInput.answers)) return undefined;
+  const answers = Object.fromEntries(
+    Object.entries(toolInput.answers)
+      .filter((entry): entry is [string, string] => typeof entry[1] === "string" && entry[1].trim().length > 0),
+  );
+  return Object.keys(answers).length ? answers : undefined;
+}
+
+function holdQuestionWithImmediateDeny(params: {
+  options: ControlServerOptions;
+  pendingPermissionRequests: Map<string, PendingPermissionWaiter>;
+  handler: ProviderPermissionPromptHandler;
+  approvalId: string;
+  body: Record<string, unknown>;
+  occurredAt: number;
+  transcriptPath: string;
+  toolName?: string;
+  toolInput?: unknown;
+}): Response {
+  const { options, pendingPermissionRequests, handler, approvalId, body, occurredAt, transcriptPath, toolName, toolInput } = params;
+  // #1173/#1194: a fresh "questions" prompt (the provider's AskUserQuestion) must not block
+  // its own hook response while the human answers. Denying immediately makes the provider persist
+  // the buffered turn plus rejected tool_result, so the pre-flush harvest below can publish the
+  // reasoning before the dashboard form appears. The eventual answer is injected as a normal prompt.
+  const response = Response.json(handler.buildHookResponse(
+    { approvalId, decision: "deny", reason: PENDING_QUESTION_DENY_REASON },
+    body,
+  ));
+  void awaitPermissionDecision({
+    options, pendingPermissionRequests, handler, approvalId, body, occurredAt, transcriptPath, toolName, toolInput,
+    blockedReason: "pendingQuestion",
+    recommendedAction: "Answer the question in Agent Relay.",
+    suppressResolvedStatus: true,
+  }).then(({ decision, view }) => {
+    const text = decision.decision === "answer" && decision.answers && Object.keys(decision.answers).length
+      ? handler.buildAnswerInjectionPrompt!(view, decision, body)
+      : pendingQuestionDismissalPrompt(decision);
+    return options.onAnswerInject?.({ approvalId, text });
+  }).catch(() => {});
+  return response;
+}
+
 // Shared by both the traditional block-until-decided flow and the #1173 deny-then-hold flow:
 // pre-flushes narrative (#435/#1116), builds+persists the interactive view, publishes the
 // blocked providerState, and resolves once a decision arrives (or the wait times out). Callers