feat: make AskUserQuestion actually ask

[ericleepi314]

Why

AskUserQuestion was registered and reachable in the interactive TUI but had never worked there. _ask_user_question_call branches on context.ask_user; the agent-server never set that hook, so every call took the dead-letter branch and returned its own questions back as {"status": "pending"} — and the default map_result_to_api JSON-dumps a dict output as the result content.

So the raw blob users saw in the transcript was the tool's return value, not a display bug, and there was no dialog to answer. The model had to fake the interaction by narrating the options in prose:

⏺ AskUserQuestion
  ⎿ {"questions": [{"header": "Scope", "question": "Which posts should I research
    and enrich?", "multiSelect": false, "options": [{"label": "The two un-sourced
    posts", "description": "Focus on 'Leadership Principles' and 'Inside DOGE' …

Now:

⏺ AskUserQuestion
  ⎿  · Which posts should I research and enrich? → The two un-sourced posts
     · How aggressively should I edit the prose? → Facts + sources only

What

A blocking control_request/control_response round trip (_AgentSession.ask_user) plus an Ink dialog: single-select, multiSelect, the auto-injected free-text row, navigation chips, back-navigation, and a review step.

Not the permission lane, even though ExitPlanMode — the other blocking interactive tool — lives there. PermissionAskReply carries only behavior/updated_input/chosen_updates and has nowhere to put structured answers; ExitPlanMode only gets away with it by smuggling its edited plan through updatedInput. This borrows the MCP-elicitation shape instead, which also keeps the tool in NO_PERMISSION_TOOLS so the questions stay the gate rather than acquiring an "Answer questions?" prompt on top of them.

Deferred (upstream has them, this doesn't): preview panes, notes/annotations, $EDITOR, image paste, plan-interview footer rows.

Defects found and fixed while building

Review found several things worth calling out, two confirmed by executing against the real component:

• Model-controlled newlines forged option rows. stripAnsi's CONTROL_RE deliberately keeps \n, and ink's wrapText splits on it even under truncate-end, so one label rendered as several rows. The digit shortcut picks by array index, not rendered row — so "Cancel\n 2. Deploy (safe)" painted a convincing fake option 2 while pressing 2 selected the real option 2. The user reads one thing and picks another. Text is now normalized once at the component boundary (not at render, so the stored answer agrees with what was shown).
• Duplicate question text collapsed answers. answers/picked/texts, the answered chip, allAnswered, the asked-set filter and the display envelope are all keyed by question text. Two questions sharing text marked an untouched question answered and submitted one key for both. Now rejected, mirroring TS UNIQUENESS_REFINE.
• A client could put words in the user's mouth. Answers are now filtered to the questions actually asked, and the model-facing prose uses json.dumps per side — a " in an answer could otherwise close its pair and forge answers to questions never asked.
• Empty answers were submitted for questions the UI called unanswered. Toggling a multiSelect option on then off serialized to '', which every surface reads as unanswered — but it was submitted anyway.
• A force-cleared overlay stranded the backend worker for up to 30 minutes with the composer back and looking ready.
• TextInput renders a Box, so it cannot live inside a <Text> — the free-text row crashed the moment it took focus. Typecheck and 38 unit tests were green; only the live pty run caught it.

The shared _pending machinery was refactored into one _round_trip, which fixed two pre-existing bugs in the permission lane for free: a leaked pending slot on a raising _emit, and an unlatched reply that a racing second response could overwrite (in that lane, turning a deny into an allow whose chosen_updates persist).

Deliberate divergences from upstream

Divergence	Why
is_concurrency_safe = false	Upstream serializes dialogs through REPL's toolUseConfirmQueue; this port has no such queue and PromptZone is an exclusive if-chain, so a second concurrent dialog would be invisible while still blocking its tool. Recorded with a _note in ts_tool_properties.json so the next parity sweep doesn't revert it.
Enter on an empty free-text row is a no-op	Upstream cancels the entire dialog (select.tsx onEmptyInputSubmit), throwing away every answer already given on a stray Enter.
Trail row stays AskUserQuestion	buildToolTrailLine returns header and detail as one string, so copying the TodoWrite suppression would delete the answers with it. Commented at the source.

Testing

114 new tests (33 Python + 81 TS). Beyond unit coverage, all four flows were driven live under a pty against the real TUI binary, asserting on the actual wire payloads:

Flow	Wire
Esc	{"action":"cancel"}
multiSelect	{"How aggressively…":"Facts + sources only, Full rewrite"} (toggle order)
free text	{"Which posts…":"only the DOGE one"} (raw text, not the __other__ sentinel)
toggle on/off	question absent entirely, not ""

• Python: 9095 passed, 0 failed.
• TS: 8 failed / 1656 passed — the same 8 pre-existing failures as baseline on 62a1422a, verified by stashing this branch and re-running. Now recorded as a P0 in TODOS.md.

Two of my own tests were flaky when first written and are fixed: fixed-duration settles lose to full-suite parallel load, and press() must wait for the stream to drain, because a coalesced chunk makes ink batch two keys into one React update and the second handler then runs against the first key's pre-commit closure.

Also in here

fix(vscode): the extension dropped every control_request except can_use_tool with no reply. Harmless when permissions were the only kind; with a 30-minute AskUserQuestion timeout it wedges the session. It now declines what it cannot present. Note the server-side single-session gate does not cover this — it keys on transport, and the extension shares --stdio with the Ink TUI.

Known gaps

Recorded in TODOS.md rather than fixed here: worker housekeeping (/loop, cron, background notifications) stalls for the length of a dialog, since it only fires from _run_worker's idle branch; and Ctrl+C on any prompt overlay leaves the status line stale (pre-existing, shared with the approval branches).

🤖 Generated with Claude Code