Bug: Multi-question tool calls fail silently in TUI since v1.17.13 (regression from #34116)

[weimantian]

Bug Summary

Since upgrading to v1.17.13, the question tool fails silently when called with 2 or more questions in the TUI. The TUI renders the question form, but pressing Enter to submit does nothing — no reply or reject event is ever sent to the backend. Single-question calls (questions=1) work perfectly.

This is a regression — multi-question calls worked reliably on v1.17.11.

Environment

• OpenCode version: 1.17.13 (installed via Homebrew)
• Platform: macOS darwin (arm64)
• TUI: Terminal (not desktop/web app)

Reproduction

1. Be on v1.17.13
2. Have the AI call the question tool with questions array containing ≥2 items
3. TUI renders the multi-question form
4. Select answers for all questions, press Enter
5. Nothing happens — the form stays open, no submission occurs
6. The tool call eventually shows as "aborted" when manually cancelled

Compare with: calling question with questions array of length 1 — works perfectly every time.

Evidence: Log Analysis

I analyzed ~/.local/share/opencode/log/opencode.log and correlated every message=asking with message=replied / message=rejected for question tool calls (filtering out permission asking entries).

Version comparison

Version	Single-question (Q=1)	Multi-question (Q≥2)
v1.17.11 (before Jul 4)	✅ All succeeded	✅ 5/7 succeeded (2 user-rejected) — includes Q=4, Q=5
v1.17.13 (Jul 4+)	✅ 10/10 succeeded	❌ 0/2 succeeded — both NO_RESPONSE

Detailed call log (v1.17.13)

2026-07-05T14:57:26 | Q=1 | REPLIED     ✅  (run=d44cf7d8)
2026-07-05T15:15:44 | Q=3 | NO_RESPONSE ❌  (run=5c771da9)  ← my first failed call
2026-07-05T15:22:08 | Q=4 | NO_RESPONSE ❌  (run=8abd6bd1)  ← my second failed call

Detailed call log (v1.17.11 — multi-question WORKED)

2026-06-27T13:04:15 | Q=5 | REPLIED ✅  (run=c3badc14)
2026-06-27T13:13:47 | Q=2 | REPLIED ✅  (run=90b04f13)
2026-06-27T13:17:01 | Q=2 | REPLIED ✅  (run=90b04f13)
2026-06-27T18:20:00 | Q=2 | REPLIED ✅  (run=fc968015)
2026-06-27T19:15:27 | Q=4 | REPLIED ✅  (run=cba656ea)

Key observation: failure mode

On v1.17.11, when a user cancelled a multi-question form, the backend received message=rejected. When they submitted, it received message=replied. Both paths worked.

On v1.17.13, the two failed multi-question calls produced neither replied nor rejected in the logs. The TUI rendered the form but the submit/cancel actions never fired — the backend's deferred was left hanging indefinitely until the tool call was externally aborted.

Single-question calls on v1.17.13 all produce replied normally.

Root Cause Analysis

Backend architecture (unchanged)

The question backend in packages/opencode/src/question/index.ts creates a Deferred on ask() and waits for either reply() or reject() to resolve it. These are triggered by the TUI/client via events. The backend logs asking on create, replied on submit, rejected on cancel — all at logInfo level.

The backend is not the problem — it's the TUI that never calls reply() for multi-question forms.

Likely regression source: PR #34116

PR #34116 ("fix(app): question UI fixes and UX improvements", merged Jul 1, included in v1.17.13) significantly reworked the question UI:

• Added minimize/restore functionality
• Made answer option lists scrollable
• Changed dialog layout

The PR was primarily for the web/desktop client (packages/app). The TUI port was supposed to be PR #34668, which is still OPEN (not merged).

However, v1.17.13's changelog includes TUI-facing changes:

• Let question prompts be minimized and restored without dismissing them (@arvsrn)
• Keep pending question requests open while reviewing them, instead of dismissing them accidentally (@eXamadeus)

This suggests some question-related TUI changes shipped in v1.17.13, and these changes likely broke the submit action's event binding for the multi-question form path. Single-question rendering may use a different code path that wasn't affected.

Expected Behavior

• Multi-question forms should submit answers when the user presses Enter (same as v1.17.11)
• If this can't be fixed quickly, consider reverting the TUI question changes until PR fix(opencode): question tool can be minimized and will scroll in the TUI #34668 is properly reviewed and merged

Workaround

Use single-question calls (questions=1) — works reliably on v1.17.13. This is what I'm doing now, but it degrades the UX for multi-step confirmations.

Additional Context

• Related PR: fix(app): question UI fixes and UX improvements #34116 (question UI changes, merged)
• Related PR: fix(opencode): question tool can be minimized and will scroll in the TUI #34668 (TUI port of question UI changes, still open)
• The regression window is v1.17.11 → v1.17.13

[github-actions]

This issue might be a duplicate of an existing issue. Please check:

• Bug: question tool crashes on submitting multi-question selection #33848: Bug: question tool crashes on submitting multi-question selection — same symptom (multi-question tool submit fails/crashes in TUI), reported on v1.17.10 before the regression window you identified.

[eXamadeus]

The changes I made this targeted were for the app (web/desktop client), not the TUI. The TUI changes I made haven't merged yet.

So not sure you're looking in the right spot. Granted there were some changes made to the PR after I pushed it, so it could be those.

But the changes I made were specifically NOT for the TUI, so I suggest double checking this analysis.

[eXamadeus]

Also, I doubt the validity of this report. I've seen multi-question tool calls in the TUI since the upgrade.

Is this observed degraded behavior or just bot slop?

[weimantian]

Closing this issue — our root cause attribution to #34116 was incorrect. We'll re-investigate and file a new issue once the actual cause is confirmed.

[weimantian]

You're right, thanks for the correction. My attribution to #34116 was premature. I'll re-investigate the actual root cause.