AskUserQuestion is unanswerable: generic Allow/Deny prompt, then "the user did not answer"

[ElbertePlinio]

Goal

Render AskUserQuestion as an answerable question card and send the user's real answers back to the agent, instead of a meaningless Allow/Deny prompt followed by "the user did not answer".

Why

The agent asked three questions. PickForge showed a generic approval prompt labelled only TOOL AskUserQuestion — no questions, no options. Pressing Allow made the agent report "No answer — I'll proceed with the recommended defaults" and continue on guesses.

That is worse than a hard failure: the user believes they answered, the agent believes they declined to, and the turn proceeds on invented defaults. Any AskUserQuestion in a Claude chat is currently unanswerable.

Verified against SDK 0.3.198 / bundled CLI 2.1.198 (package.json:25).

Root cause

The permission prompt is not an SDK bug — it is the hand-off. AskUserQuestion declares requiresUserInteraction() { return true }, and that check runs before the bypass branch in the SDK's permission evaluator. So the tool routes through canUseTool even under Bypass permissions, by design, and its checkPermissions() returns {behavior: "ask", updatedInput: {questions}} — the SDK is handing the host the questions to render. The SDK's own TUI answers it by returning {behavior: "allow", updatedInput: {...input, answers, annotations}}.

PickForge treats it as an ordinary allow/deny, and loses the questions at three separate layers:

1. The bridge allows without answering. scripts/claude-bridge.ts:280-291:

if (decision === "accept" || decision === "acceptForSession") {
  return { behavior: "allow", updatedInput: input };
}

input here is {questions, metadata?} — the SDK strips answers before the callback. With no answers key, the tool's own result text is literally "The user did not answer the questions." That is the string the user saw rendered as "No answer".

2. The store drops the questions. parseApprovalDetail (src/stores/agentChat.ts:380-406) extracts only command / cwd / reason / toolName from the approval detail. The full input — including questions — arrives intact on AgentApproval.detail (claude_bridge.rs:734-744 preserves it) and is never read.

3. The card has nothing to show. ApprovalPrompt.tsx:13-15:

function headline(approval: AgentApproval): string {
  return approval.parsed?.command ?? approval.parsed?.toolName ?? approval.detail;
}

For any non-Bash tool that resolves to the tool's bare name — hence TOOL AskUserQuestion and nothing else. There is no per-tool renderer anywhere in the approval path (claude_bridge.rs:882-888 and ApprovalPrompt.tsx:7-11 are the only tool/kind switches, neither covers this).

The contract to satisfy

Return from canUseTool:

{ behavior: "allow", updatedInput: { ...input, answers, annotations?, response? } }

• answers: Record<questionText, string> — keyed by the exact question string, not header.
• Multi-select answers are a single ", "-joined string ("A, B"), not an array.
• annotations: Record<questionText, { preview?, notes? }> for the selected option's preview and the user's free-text notes.
• Free text goes in updatedInput.response, not in answers.
• An empty answers object still yields the "did not answer" fallback — omit empty keys entirely.

Scope

A1. Bridge — answer, don't merely allow. scripts/claude-bridge.ts

• Extend the approve op with an optional structured payload {answers, annotations?, response?}; the existing four decisions stay untouched for every other tool.
• permissionResultForDecision (:280) builds the updatedInput above when a payload is present.
• Exempt AskUserQuestion from gate.alwaysAllow (:311-312). approvalScopeKey (:72-84) collapses every question to AskUserQuestion\0"", so one "Allow for session" would silently auto-answer every future question with a stale reply. This is a latent data-corruption path, not a nicety.
• Map decline to the SDK's clarify shape so the model can rephrase rather than hard-fail.

A2. Core — carry the kind and the payload.

• event.rs:171 — add ApprovalKind::Question.
• claude_bridge.rs:882 approval_kind — "AskUserQuestion" → Question.
• Thread the optional answer payload through claude_bridge.rs:332 chat_approve → manager.rs:1429 approve → src-tauri/src/agent_chat_commands.rs:281 → src/lib/agentChat.ts:351. No new event field is needed inbound: detail already carries the full input.

A3. Store + card.

• parseApprovalDetail (agentChat.ts:380) surfaces typed questions; approveAgentRequest (:2038) forwards the payload.
• New src/components/chat/QuestionPrompt.tsx, dispatched from ApprovalPrompt.tsx on kind === "question". Full parity with the CLI: option label + description, multiSelect where asked, free-text "Other", per-question notes → annotations. Submit disabled until every question is answered; secondary action maps to clarify.
• Design: run design-director. Two standing rules for this app — status reads as bracket-cornered mono text, never a filled chip; telemetry anchors to an edge that already exists rather than adding chrome.

Acceptance criteria

• An AskUserQuestion renders its questions and options; the generic Allow/Deny prompt never appears for it.
• Answering sends answers keyed by exact question text; the agent's tool result reads "Your questions have been answered", never "The user did not answer the questions."
• Multi-select produces a ", "-joined string; notes and free text arrive as annotations / response.
• "Allow for session" can never auto-answer a later question.
• Declining lets the model rephrase instead of failing the turn.

Validation

• tests/unit/claudeBridge.test.ts — regression first (allow-without-answers is the current broken shape), then the answered path, multi-select joining, and the alwaysAllow exemption.
• Rust: approval_kind("AskUserQuestion") == Question; the payload reaches the child's stdin (extend the fake-bridge stdin-log assertion at claude_bridge.rs:1347).
• tests/unit/agentChat.test.ts — questions parsed from detail; payload reaches invoke("agent_chat_approve", …).
• Component test for QuestionPrompt (single, multi, notes, Other) + a VRT fixture — there is no approvalRequest in tauriMock.ts today.
• Live E2E, new tier. No test in this repo reaches the real CLI: bridge tests mock the SDK and put a zero-byte claude on PATH (claudeBridge.test.ts:94), Rust tests spawn #!/bin/sh fakes, VRT runs against tauriMock.ts, bun run e2e mocks invoke. Add an opt-in tests/e2e/claude-live.ts, env-gated in the style of the existing device tiers and skipped in CI, that runs the real bridge against the real claude CLI on Haiku 4.5, forces an AskUserQuestion, answers it through the approve op, and asserts the resulting tool result.
• Manual: run the app from the worktree with a distinct dev port and version suffix per AGENTS.md, answer a three-question prompt, confirm the agent proceeds on the given answers.

Flag

No flag. Self-contained bug fix on an existing surface, shipping in the next release — the release tag is the switch (workspace AGENTS.md, "Feature flags").

Notes

• ExitPlanMode also declares requiresUserInteraction and will hit the same generic prompt. Out of scope; follow-up issue to be filed from this PR.
• Related but distinct: MCP tool rows in chat are dead ends: no args, no result, no completion — and pickforge-lanes should show lane cards #362 owns MCP tool rows and the shared timeline status/detail plumbing.

[ElbertePlinio]

#394 merged — the live E2E tier this issue asked for now exists, and it changes what we know.

Before it, every layer was mocked: the bridge tests mock the SDK and put a zero-byte claude on PATH, the Rust tests spawn #!/bin/sh fakes, VRT runs against tauriMock.ts, bun run e2e mocks invoke. So the contract that actually matters — that returning {behavior: "allow", updatedInput: {...input, answers}} makes the tool report answers rather than "The user did not answer the questions." — was asserted against a reading of the SDK.

PICKFORGE_E2E_CLAUDE=1 bun run e2e:claude drives the real binary through the real bridge, forces an AskUserQuestion, answers it through the same approve op the GUI uses, and asserts the tool's own result text.

Verified load-bearing against the live tool:

answers branch enabled	PASS — the tool accepted the answer
answers branch disabled	FAIL — "the tool reported that the user did not answer"

That is the first direct evidence the fix works, and it reproduces the exact user-visible string from the report.

Gating follows the device tiers: unset → SKIP exit 0 so CI stays green without credentials; gate set with claude missing → fail fast, because a silent pass is worse than no test. Pinned to a cheap model per the repo's dogfooding convention.

One finding worth knowing, now in tests/e2e/README.md: wait for a raw result message, not turnClosed. The bridge emits turnClosed only when the whole query iterator ends, because a session stays open for follow-up sends — waiting on it hangs until timeout even though the turn succeeded. That cost a debugging cycle.

Every acceptance criterion on this issue is now met and proven end to end.

Remaining, as noted when the fix landed: ExitPlanMode also declares requiresUserInteraction and will hit the same generic prompt — worth its own issue. And there is still no VRT fixture for an approval prompt (tauriMock.ts has no approvalRequest), so QuestionPrompt has component coverage but no snapshot.