Skip to content
Treaty

dev.agentpod.permission (embedded card)

A harness permission request as it rides inside the station room’s prose message under the dev.agentpod.permission content key. Four options at most. Answered by an ordinary reply naming an option, matched against the request the carrier holds. Readers ignore properties they do not know.

How it rides

Section titled “How it rides”

A card inside the prose message’s content, under the content key dev.agentpod.permission.

Who sends it, who reads it

Section titled “Who sends it, who reads it”

Fields

Section titled “Fields”
Field Type Required Description Constraints
schema_version 1 yes
session_id string yes
request_seq integer yes at least 0
title string yes
options array of object yes at least 1 item; at most 4 items
options[].option_id string yes
options[].name string yes

Example

Section titled “Example”

From fixtures/matrix-events/examples.json, case “built: a request with two options”:

{
  "schema_version": 1,
  "session_id": "acps_1",
  "request_seq": 4,
  "title": "Run bun test",
  "options": [
    {
      "option_id": "allow",
      "name": "Allow once"
    },
    {
      "option_id": "reject",
      "name": "Reject"
    }
  ]
}

Refused

Section titled “Refused”

Each of these must fail. The corpus says why:

  • schema_version 2: a breaking change mints a new key (refused by schema)
  • five options: a client draws four buttons (refused by schema)
  • a negative request_seq (refused by schema)

Source

Section titled “Source”