fix(chat): give AskUserQuestion a real answer channel

The harness answered every question itself, instantly, with "The user did not
answer the questions." — before the card had painted, let alone been read. The
agent then reasoned about a refusal that never happened: on 2026-08-19 it asked
the same question three times in a row while the answers sat on the screen.

The web UI already worked around it by rendering the card ungated and sending
the click back as an ordinary chat message. That got an answer through, but the
agent read it as a new instruction arriving from nowhere rather than as the
reply to what it asked, and nothing could distinguish a live question from one
answered last week — every replayed transcript rendered its old questions as
clickable.

A PreToolUse hook is the fix, and it has to be a hook rather than canUseTool:
under bypassPermissions — which is every session here — the SDK shadows the
callback and never calls it. Measured against 0.2.59: a bypassing session's
AskUserQuestion reached the hook and never reached canUseTool. Hooks run
regardless of permission mode.

The hook parks on a promise keyed by the harness's own tool_use_id, and returns
`deny` with the human's answer as the reason — which the harness feeds back as
the tool result verbatim. "Deny" reads wrong and is right: what it denies is the
tool's ability to answer for the user, and what replaces its output is what the
user actually said. Held open for 150s in testing with the turn completing
normally, so a person has time to think.

Keying on tool_use_id rather than an invented id means no new durable event: the
questions are already in the session log as an ordinary tool:start, and the
answer arrives as its tool:result. One source of truth, replay included — which
is what re-enables gating the card on `output`, and with it the staleness fix.
The two tests that pinned the old ungated behaviour asserted the workaround as
the contract; they now pin the reversal, including a pre-fix transcript reading
as settled, which it is.

Unanswered questions settle like plans do: 20 minutes, every session-ending path
draining them first, and wording that tells the agent the question is still on
the user's screen and must not be asked again.

Mobile (Butler) has the same workaround and is not fixed here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/api/chat/websocket.ts

@@ -243,6 +243,8 @@ export function message(ws: ServerWebSocket<WSData>, raw: string | Buffer): void
         await handlePlanMode(ws, clientMsg);
       } else if (clientMsg.type === 'plan:decide') {
         handlePlanDecision(ws, clientMsg);
+      } else if (clientMsg.type === 'question:answer') {
+        handleQuestionAnswer(ws, clientMsg);
       }
     } catch (err) {
       logger.error('Error handling WebSocket message', { email: ws.data.email, error: String(err) });
@@ -1270,6 +1272,25 @@ function handlePlanDecision(
   });
 }
 
+/**
+ * Relay the user's answer to the question the agent is blocked on.
+ *
+ * Silent like its plan sibling, and for a stronger reason: the answer's own receipt is the `tool:result`
+ * the sidecar emits when this unblocks it, which is durable and reaches every socket on this conversation.
+ * A direct reply would confirm to the one browser that clicked, and leave a second pane showing a question
+ * that is already answered.
+ */
+function handleQuestionAnswer(ws: ServerWebSocket<WSData>, msg: { toolCallId: string; answer: string }): void {
+  const sessionId = wsToSessionMap.get(ws);
+  if (!sessionId) return;
+  sidecar.answerClaudeQuestion({
+    sessionKey: sessionId,
+    userId: ws.data.userId,
+    toolCallId: msg.toolCallId,
+    answer: msg.answer,
+  });
+}
+
 async function handleStop(ws: ServerWebSocket<WSData>): Promise<void> {
   const sessionId = wsToSessionMap.get(ws);