[ACP] User choices arrive as allow_once permission options instead of a structured question

Google Antigravity
1

This report concerns the standalone Antigravity ACP server (agy_acp_server.par) used by an ACP client.

Environment

  • Client: Kepler 0.11.0
  • OS: macOS, Apple Silicon
  • Antigravity session mode: ACP, default permission mode
  • Exact ACP server version: not yet verified

Observed behavior

In an existing coding session, the agent asked me to choose how to proceed with pending file changes. The three choices were mutually exclusive next actions, rather than approval tiers for one concrete tool call.

Kepler persisted the interaction as type: "permission_request", with three options whose kind was "allow_once". The following is a sanitized representation of the persisted client record; it is NOT a raw wire capture:

{
  "type": "permission_request",
  "toolCall": {
    "toolCallId": "interaction_<redacted>",
    "status": "pending",
    "title": "Please choose how to handle the pending file changes",
    "rawInput": {}
  },
  "options": [
    { "optionId": "1", "name": "Commit and push the pending changes", "kind": "allow_once" },
    { "optionId": "2", "name": "Restore the files and keep the working tree clean", "kind": "allow_once" },
    { "optionId": "3", "name": "Inspect other changes first", "kind": "allow_once" }
  ]
}

The original option labels were longer sentences. Kepler displayed them as permission buttons in one horizontal row and added its own “Allow for this session” button. The choices became difficult to read, and session-wide approval is confusing for a one-time choice about what to do next.

Expected behavior / question

Could the ACP server send these user-choice interactions through a structured question / elicitation mechanism when the client supports it, or use a plain-text question as a fallback? Permission requests should preserve the semantics of approving or rejecting a specific operation.

Is representing all three next-action choices as allow_once intentional compatibility behavior, or a mapping issue in the ACP server?

Reproduction status and scope

  • Observed once in a real session; not reproduced on demand yet.
  • Evidence is the client-persisted interaction and the rendered UI; raw ACP stdout was not captured.
  • A separate Kepler feedback report has been submitted for wrapping / stacking long permission option labels. That layout is client-side; this report asks about the server-side semantics.
  • Private repository names, commit IDs, paths, and business content have been removed.