Repository navigation
Bug: Multi-question tool calls fail silently in TUI since v1.17.13 (regression from #34116) #35434
Description
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
- Be on v1.17.13
- Have the AI call the
questiontool withquestionsarray containing ≥2 items - TUI renders the multi-question form
- Select answers for all questions, press Enter
- Nothing happens — the form stays open, no submission occurs
- 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
Activity
github-actions commentedon Jul 5, 2026
This issue might be a duplicate of an existing issue. Please check:
eXamadeus commentedon Jul 5, 2026
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 commentedon Jul 5, 2026
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 commentedon Jul 5, 2026
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 commentedon Jul 5, 2026
You're right, thanks for the correction. My attribution to #34116 was premature. I'll re-investigate the actual root cause.
maxiedaniels commentedon Jul 20, 2026
I am also seeing this issue. When this occurs, attempting to fork or revert a conversation doesn't work either, EXCEPT 'fork' does actually fork in the background but the UI doesn't reflect it until i re-open the session list and see the tons of forks I accidentally created by clicking fork repeatedly.
maxiedaniels commentedon Aug 25, 2026
@weimantian Sorry im confused, why is this closed? Im experiencing this all the time, it's very frustrating. A report if it helps:
I did a live reproduction of the multi-question TUI submission failure.
Environment:
Identifiers:
The UI renders all three questions and the Confirm review screen correctly.
Pressing Enter on Done/Confirm has no visible effect.
The SQLite part remains:
The last relevant log entry is:
timestamp=2026-08-25T21:17:42.265Z level=INFO run=3ce3e8f7 message=asking id=que_03ac93df9001f6xkQnpUNPmK4y questions=3
Repeated submission attempts create no subsequent answered/completed/error log entry
and no corresponding database update. This suggests the TUI submit action is not
reaching the question backend rather than the backend rejecting the answers.
I've recorded logs and data relevant if it'll help. I should note, im using Cmux which has hooks for opencode, so it's plausible there's an issue there. I actually have a report open on the Cmux github, but last I analyzed, it was due to a memory leak issue in opencode.