Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
OpenCode has a useful question tool for asking the user structured questions with options. This is important product behavior: the agent can pause, ask for a decision, and continue after the user answers.
Today this works in OpenCode’s own interactive surfaces, but ACP clients do not appear to receive a stable interactive request for it.
For ACP clients, the agent can still describe a question in plain chat text, but the client cannot render it as a proper choice UI, cannot distinguish it from ordinary assistant text, and cannot reply through a structured answer path.
User impact
This blocks several important UX flows for ACP-based IDE clients:
- Clarifying questions before implementation
- Interview-style onboarding or setup flows
- Choosing between several implementation approaches
- Test/question flows where the user should pick an option
- Plan/design flows where the agent needs an explicit user decision before continuing
Without a structured ACP question flow, users have to read the assistant text, manually type an answer, and send another prompt. That is slower, less reliable, and loses the clear “agent is waiting for my decision” state.
Expected behavior
When the model calls OpenCode’s question tool during an ACP session, the ACP client should receive a stable interactive request that contains enough information to render the question UI.
For example, the client should be able to show:
- Question header/title
- Question text
- One or more options
- Whether multiple options can be selected
- Whether a custom/free-form answer is allowed
- A clear cancel/reject path, if applicable
The ACP client should then be able to send the selected answer back to OpenCode, and the agent should continue the same turn/session using that answer.
Product-level flow:
agent asks structured question
-> ACP client shows choices
-> user selects answer
-> agent continues
Actual behavior
ACP clients currently only have a reliable structured interaction for tool permission approval via session/request_permission.
That permission flow is not the same product scenario as the question tool:
- permission approval asks whether a tool/action is allowed;
- question asks the user for a product/task decision.
As a result, ACP clients cannot provide the same interactive question UX that OpenCode can provide internally.
Related OpenCode behavior
OpenCode already has internal support for this kind of interaction:
- question tool for user questions
- question.asked / reply-style interaction in OpenCode’s own runtime/UI
- plan_exit also appears to rely on question-like behavior for plan approval
So the missing piece is not the product concept itself, but a stable ACP-facing contract for clients.
Why this matters for ACP clients
ACP is used by external/editor clients that need to render agent interaction in their own UI. These clients need to know when the agent is actually waiting for user input.
Plain assistant text is not enough because the client cannot reliably know:
- that this is a blocking question;
- what options are available;
- whether the user can pick multiple options;
- whether custom input is allowed;
- how to send the answer back without starting a disconnected new prompt.
A first-class ACP interaction would make question flows predictable and consistent across clients.
Requested improvement
Please expose OpenCode’s question tool over ACP as a stable interactive client request.
Ideally the contract should document:
- request shape
- response shape
- cancel/reject behavior
- single-select vs multi-select behavior
- custom/free-form answer behavior
- whether the agent turn remains pending while waiting for the answer
- how this relates to session/request_permission
- whether plan_exit / plan approval should use the same mechanism
Non-goals
This is not a request to change the existing permission approval flow.
session/request_permission is still useful for tool permissions. The requested feature is a separate product interaction for user decisions/questions.
Suggested acceptance criteria
- During an ACP session, when the agent calls question, the ACP client receives a structured request instead of only assistant text.
- The request includes question text and options.
- The client can answer or cancel the question.
- The agent continues the same session/turn after receiving the answer.
- The behavior is documented so ACP client implementers can support it reliably.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
OpenCode has a useful
questiontool for asking the user structured questions with options. This is important product behavior: the agent can pause, ask for a decision, and continue after the user answers.Today this works in OpenCode’s own interactive surfaces, but ACP clients do not appear to receive a stable interactive request for it.
For ACP clients, the agent can still describe a question in plain chat text, but the client cannot render it as a proper choice UI, cannot distinguish it from ordinary assistant text, and cannot reply through a structured answer path.
User impact
This blocks several important UX flows for ACP-based IDE clients:
Without a structured ACP question flow, users have to read the assistant text, manually type an answer, and send another prompt. That is slower, less reliable, and loses the clear “agent is waiting for my decision” state.
Expected behavior
When the model calls OpenCode’s
questiontool during an ACP session, the ACP client should receive a stable interactive request that contains enough information to render the question UI.For example, the client should be able to show:
The ACP client should then be able to send the selected answer back to OpenCode, and the agent should continue the same turn/session using that answer.
Product-level flow:
Actual behavior
ACP clients currently only have a reliable structured interaction for tool permission approval via session/request_permission.
That permission flow is not the same product scenario as the question tool:
As a result, ACP clients cannot provide the same interactive question UX that OpenCode can provide internally.
Related OpenCode behavior
OpenCode already has internal support for this kind of interaction:
So the missing piece is not the product concept itself, but a stable ACP-facing contract for clients.
Why this matters for ACP clients
ACP is used by external/editor clients that need to render agent interaction in their own UI. These clients need to know when the agent is actually waiting for user input.
Plain assistant text is not enough because the client cannot reliably know:
A first-class ACP interaction would make question flows predictable and consistent across clients.
Requested improvement
Please expose OpenCode’s question tool over ACP as a stable interactive client request.
Ideally the contract should document:
Non-goals
This is not a request to change the existing permission approval flow.
session/request_permission is still useful for tool permissions. The requested feature is a separate product interaction for user decisions/questions.
Suggested acceptance criteria