ACP: AskUserQuestion does not expose the automatic Other custom-input option

Summary

Kimi Code's AskUserQuestion tool automatically provides an Other option for free-form input in the TUI/web experience. The official built-in tools documentation also states that the Other option is appended automatically.

In ACP mode, however, the AskUserQuestion bridge exposes only the question's declared fixed options plus a trailing Skip option. There is no supported way for an ACP client to return arbitrary user-entered text, so users cannot provide a custom answer when none of the fixed choices fit.

This makes AskUserQuestion behavior in kimi acp less capable than the documented native Kimi experience.

Official documentation

• Built-in tools: https://www.kimi.com/code/docs/en/kimi-code-cli/reference/tools.html
  • AskUserQuestion accepts structured choices and automatically appends an "Other" option.
• ACP adapter: https://www.kimi.com/code/docs/en/kimi-code-cli/reference/kimi-acp
  • session/request_permission is documented as the shared channel for tool approval and question elicitation.

Environment

• @moonshot-ai/kimi-code: 0.31.1
• Platform: Windows 11
• ACP client: WheelMaker (implements session/request_permission)

Steps to reproduce

1. Start Kimi with kimi acp from an ACP client that implements session/request_permission.
2. Ask Kimi to call AskUserQuestion with two or more fixed options.
3. Inspect the session/request_permission payload sent to the client.
4. Observe that the request contains only q0_opt_<index> entries and q0_skip; no Other/custom-input option or custom-answer transport is exposed.
5. A client cannot synthesize its own option because the adapter treats an unknown optionId as dismissal.

Actual behavior

The ACP adapter's questionItemToPermissionOptions maps question.options to fixed allow_once choices and appends only Skip. outcomeToQuestionAnswer accepts only q0_opt_<index> and maps any unknown option ID to null.

Relevant source:

https://github.com/MoonshotAI/kimi-code/blob/main/packages/acp-adapter/src/question.ts

As a result, an ACP client can select a fixed answer or dismiss the question, but cannot provide the free-form Other answer supported by Kimi's native UI.

Expected behavior

kimi acp should expose a supported, documented way for ACP clients to:

1. Show the automatic Other option.
2. Submit user-entered free-form text for that option.
3. Have that text returned to AskUserQuestion as the answer value.
4. Preserve compatibility with ACP clients that only return existing fixed optionId values.

Possible implementations could use a documented ACP _meta extension or an appropriate elicitation primitive. The exact wire shape should be defined by Kimi so ACP clients do not have to invent incompatible provider-specific payloads.

Additional question

Is the missing Other path an intentional limitation of the stable session/request_permission response schema? If so, could the limitation and the recommended extension mechanism be documented?

Start with packages/acp-adapter/src/question.ts, especially questionItemToPermissionOptions and outcomeToQuestionAnswer, then compare their behavior with the documented session/request_permission flow. Done means ACP clients can display and submit the automatic Other answer while existing fixed optionId responses remain compatible, with the supported wire mechanism documented.