Ask Tool using Dialog TUI

[dbpolito]

This introduces a ask tool and a iterative way to answer that using Dialog TUI, we currently support 4 question types:

1. Select
2. MultiSelect
3. Confirm
4. Text

I tried to use the components we already have to make it simpler.

We probably want to make this dialog bigger, improve some UX but i kept it as simple so we can hear input from community.

[DamianB-BitFlipper]

Looks super cool. There should be a way to have the ask tool disabled (if we want to run opencode in a non-interactive way).

[wienans]

Agree with @DamianB-BitFlipper but i think that should be the same thing as with all the other tool in the config via : "deny" ?

Looks super cool would love to see it land in OC

[shuv1337]

I like this one too. I merged it into my fork today, plus the suggested modifications to make it configurable via config. I opted to enable it by default for the built-in plan mode and disable it by default for everything else to align with what people might expect coming from claude code.

What Changed (to address PR concerns)

• Default tool gating now matches “Claude Code”-style expectations: ask is enabled by default only for the built-in plan agent, and disabled by default for other agents (build, subagents, and even hidden title/summary). See packages/opencode/src/agent/agent.ts:51.
• Plan-mode reminder now nudges the plan agent to prefer the interactive ask tool when it’s available (instead of plain-text questions). See packages/opencode/src/session/prompt/plan.txt:17.
  How To Disable/Enable ask
• Users can fully disable it (including for plan) via config: tools: { "ask": false } (this overrides the plan default). Verified by test at packages/opencode/test/config/config.test.ts:526.
• Users can opt-in enabling it for other agents via config: tools: { "ask": true }. Verified by test at packages/opencode/test/config/config.test.ts:548.

[shuv1337]

One more issue:

The current ask UI was rendering all questions + all options inline in a plain <box>, so on small terminals (or with many questions/options / long question text) it can push content past the bottom with no way to reach it.

Fixes implemented

• Made the multi-question ask dialog body scrollable via scrollbox, with a max height derived from terminal size so it never grows off-screen. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question.tsx:51.
• Collapsed non-active questions into a single-line summary (question + current answer preview) and only expanded the currently selected question. This drastically reduces vertical space when multiple questions are asked together. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question.tsx:200.
• Added auto-scroll-to-active-question when you tab between questions, so the active one stays visible even in long lists. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question.tsx:98.
• Made select question options scrollable + auto-scroll-to-selected-option, so large option lists work on small screens. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question-select.tsx:24 and packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question-select.tsx:103.
• Fixed multi-select UX (it previously had focusedIndex hardcoded to 0, so you couldn’t actually navigate options) and added scrolling + focus highlight. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question-multi-select.tsx:18 and packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question-multi-select.tsx:137.
  ###Keyboard behavior after this change
• tab / shift+tab: move between questions (same as before)
• ctrl+u / ctrl+d: scroll the overall question list when it’s longer than the viewport. See packages/opencode/src/cli/cmd/tui/component/dialog-question/dialog-question.tsx:168.
• Inside select: ↑/↓, pgup/pgdn, home/end navigate options, and the view follows selection.
• Inside multi-select: ↑/↓, pgup/pgdn, home/end move focus; space toggles; view follows focus.

[dbpolito]

Just to cross reference here to, there is another PR #5958 from @iljod solving this feature in a different way, which is looking pretty good too...

Posting here because i'm more excited about the feature than the implementation, so just to hear from whoever is watching this PR their thoughts.

[malhashemi]

Hi @dbpolito ,

I really like this one, do you think we can somehow turn this into a plugin? I think the general consensus would be to keep the OpenCode codebase more focused and to extend the additional toolings via community plugins. This also ensures that you have control over the development of the feature and the direction you would like to take. Now you would most likely get hit by a feature here and there that is still not doable via plugins. This is where you would aim to extend the OpenCode core functionality to allow plugins to do what you want. Think of Core OpenCode as the infrastructure and plugins as the extended tooling. Think bigger what if you can ask the question to a human who is away from his OpenCode session? Or in a headless OpenCode? What if that same structured question can be later rendered by a slack bot, etc.

Just my experience from maintaining one of the plugins (till it might probably graduate to a core feature when it matures well enough)

@rekram1-node can correct me if anything I said isn't accurate.