[Juliusolsson05]

Fixes #1025.

The problem

Since #878 the modal showed the agent's question but offered one action — Reject. A user could read "Do you prefer the color red or blue?" and still have no way to answer it.

The option list was never missing

foldQuestion's comment said:

opencode's question payload carries no parsed option list at this seam

That was stale. LiveStateProjector.questionFromPayload sets metadata to the whole raw payload, so questions[].options has been sitting there the entire time — the permission view already reads metadata the same way. That comment is why this shipped reject-only.

Wire contract, verified against the shipped binary

The repo's rule is to confirm against the runtime binary, not the 1.14.39 vendored checkout. Both agree here:

• strings on out/main/runtime/opencode/darwin-arm64/opencode contains /question/:requestID/reply.
• The schema annotates answers as "User answers in order of questions (each answer is an array of selected labels)" — positional, labels not indices.
• The package's own conditions test already records question.replied with answers: [['Yes']].

opencode-headless already had replyQuestion; no package change was needed.

Why the view gains state — and how the boundary survives it

The rule in this subsystem is that the runtime is the single source of truth for which choices exist. A single question fits perfectly: one action per option, one click, done — unchanged.

A multi-question prompt does not. answers is positional and submitted once, so the user must choose per question and then submit, and that is selection state a runtime cannot hold.

Layer	Owns
Runtime	parses the payload, publishes the options, validates every submitted label against what it published
View	composes the selection, renders one block per question

The view may compose a choice; it can never invent one. validateQuestionAnswers refuses an unoffered label, a label borrowed from another question, the wrong arity, and an empty selection for a question that has options — while allowing the empty answer exactly where the provider offered nothing.

Options are filtered out of the modal footer, because the same options render beside their question — unfiltered, every option appeared twice, once with a question attached and once without.

Parsing and validation are pure exported functions rather than private methods, so both are driven directly by tests instead of only when a whole session exists.

Tests

The single-question payload is the real recorded one from packages/opencode-terminal-headless/testing/fixtures/live/question-reject.json, and the first test asserts the recording really carries options so nothing below can pass vacuously. The multi-question case has no recording and is built from the wire schema — labelled as such rather than dressed up as evidence.

Mutation	Result
accept any label, offered or not	2 failed
drop the arity check	1 failed
leave the footer unfiltered	3 failed
parser ignores options	1 failed
parser drops header	1 failed

npx tsc -b clean; src/providers/opencode/ green (13 files / 74 tests).

Known limitation

No multi-question stream has been captured, so that path is built from the schema. The wire allows several selected labels per question; nothing observed emits more than one, so the view picks one per question while the payload still carries the array shape.

🤖 Generated with Claude Code

[Juliusolsson05]

Review round addressed in fd5afd7f. All three blockers fixed, plus 5, 6 and 7.

1 and 2 were the same bug seen from two sides — a question can be replaced while the user is mid-answer, and every half of this flow assumed it could not. The view kept the previous question's picked map (the outlet keys on condition.kind, foldQuestion overwrites in place, so it is the same component instance); the runtime validated against the live question and replied to the payload's, then deleted the modal unconditionally. The selection is now stamped with its question and read through the stamp; both runtime arms go through a shared liveQuestion guard, and clearResolvedQuestion re-checks after the await so an in-flight reply cannot tear down a question that arrived meanwhile. Reject had the same unconditional delete before this PR and is fixed by the shared guard.

3 was the finding that mattered most. You were right about the cause: optionActions() hand-wrote a second copy of what foldQuestion publishes, so the renderer suite asserted against the copy. opencodeSession.questions.test.ts now drives the real session with the real recorded payload through the real screen event, and derives its expectations from the recording instead of restating a literal.

Your four green mutations are all red now:

mutation	before	after
no per-option actions at all	77/77 pass	1 failed
skip validateQuestionAnswers	77/77 pass	1 failed
reply with a hardcoded [['WRONG']]	77/77 pass	2 failed
never clear the modal	77/77 pass	2 failed

And the new guards are covered too: dropping the id comparison fails 2, clearing unconditionally fails 1, letting the stale selection survive fails 1, re-adding the some(needsAnswer) gate fails 1. Restored: 89 passed.

4 I did not fix here — it is pre-existing shared conditions-core behaviour affecting every provider, and with 1 and 2 fixed the silence no longer hides a wrong answer. Filed as #1070 with your analysis.

Thanks — 1 and 2 were genuinely invisible from where I was standing.