Summary
ACP clients currently have no way to let users answer AskUserQuestion with free text — they can only pick from the declared options. The CLI's own UI auto-adds a synthetic "Other" free-text option (the tool schema even tells the model not to add one because the system does), but that option is unreachable for ACP clients.
Details
session/request_permission bridge (packages/acp-server/src/question.ts): answers are accepted only when outcome.selected.optionId matches /^q{n}_opt_(\d+)$/ and indexes a declared option; anything else (including a client-invented "other" id) resolves to null = dismissed. The RequestPermissionResponse shape has no text field.elicitation/create bridge (form mode): single-select answers must equal a declared label, and out-of-set multi-select values are dropped defensively.- The source is explicit about the gap: "The synthetic 'Other' free-text option (
otherLabel) has no elicitation equivalent without an extra text field; it stays unsupported for now, matching the request_permission bridge."
Impact
ACP clients (editors, desktop shells like Zed or custom Electron clients) must render questions as closed option lists. Users who want to answer "something else" can only dismiss the question and send a separate message, losing the question context.
Suggested designs (any of)
a. In elicitation/create form mode, allow an optional per-question free-text field (e.g. allowFreeText: true on the question, and accept a text answer alongside/in place of the selected label).
b. Extend the request_permission bridge with a kimi-specific response extension carrying free text.
c. Bridge the synthetic "Other" option itself: when present, answer it via a follow-up client→agent session/prompt-style injection handled by the server.
Environment
kimi-code 0.38.0, Windows x64 native binary, custom ACP client (fs + terminal capabilities advertised).
Summary
ACP clients currently have no way to let users answer
AskUserQuestionwith free text — they can only pick from the declared options. The CLI's own UI auto-adds a synthetic "Other" free-text option (the tool schema even tells the model not to add one because the system does), but that option is unreachable for ACP clients.Details
session/request_permissionbridge (packages/acp-server/src/question.ts): answers are accepted only whenoutcome.selected.optionIdmatches/^q{n}_opt_(\d+)$/and indexes a declared option; anything else (including a client-invented "other" id) resolves tonull= dismissed. TheRequestPermissionResponseshape has no text field.elicitation/createbridge (form mode): single-select answers must equal a declared label, and out-of-set multi-select values are dropped defensively.otherLabel) has no elicitation equivalent without an extra text field; it stays unsupported for now, matching therequest_permissionbridge."Impact
ACP clients (editors, desktop shells like Zed or custom Electron clients) must render questions as closed option lists. Users who want to answer "something else" can only dismiss the question and send a separate message, losing the question context.
Suggested designs (any of)
a. In
elicitation/createform mode, allow an optional per-question free-text field (e.g.allowFreeText: trueon the question, and accept atextanswer alongside/in place of the selected label).b. Extend the
request_permissionbridge with a kimi-specific response extension carrying free text.c. Bridge the synthetic "Other" option itself: when present, answer it via a follow-up client→agent
session/prompt-style injection handled by the server.Environment
kimi-code 0.38.0, Windows x64 native binary, custom ACP client (fs + terminal capabilities advertised).