exec.*
Execution approval RPC methods
exec.* is the approval surface for runtime exec-tier gating. The runtime ships two real JSON-RPC methods (exec.approval.resolve, exec.approvals.pending); the rest of the approval UX — exec.approval.request, the approval card, the Ask / Auto / Full switch — lives in the agent loop and is reached through chat.send or agent.run, not over this namespace.
The 26.7.15+ Ask/Auto/Full exec-tier gate fires from src/tools/scoped/ (the action-aware approval card and the bypass of the slash fast-path, tools.invoke, and background continuations). The wiring details live in docs/superpowers/specs/2026-05-21-gateway-robustness-kit-design.md; this page only documents the RPC surface.
Methods
exec.approval.resolve
Resolve a pending approval with a decision. The resolved approval is a one-shot grant (allow_once) or a longer-lived scope (allow_session, allowlist).
| Parameter | Type | Required | Description |
|---|---|---|---|
id | string | yes | Approval id (carried on the AskUser / approval frame) |
decision | string | yes | allow_once / allow_session / allowlist / deny |
resolved_by | string | no | Display name of the operator resolving the card |
reason | string | no | Free-text reason, relayed verbatim to the model on deny so the next turn can re-plan on the actual objection. Ignored on allow_*. |
Response: { "ok": true } when the approval id was found and resolved; otherwise INVALID_PARAMS with Approval not found or already resolved: <id>.
exec.approvals.pending
List every approval still awaiting a decision. Read-only; the card and the tool both consume from the same in-memory map.
Response: { "pending": [ ...PendingApproval... ] }.
Each PendingApproval carries the tool call, the grant scopes the operator can pick, and the original agent session key, so a Panel reload can re-render any in-flight card.
Methods that are not RPC
The following methods are described in older versions of this page but are not registered on the current aleph-server:
| Method | Why it is not an RPC |
|---|---|
exec.approval.request | The model never calls this — the action-aware gate in src/tools/scoped/ raises the approval card on the event bus when the declared metadata flips. |
exec.approvals.get | There is no "approval config" to read — grants are in-memory only (once / session), no disk shape. |
exec.approvals.set | Same reason. There is no config to write. |
If a client wants to drive the flow programmatically, the only legal entry points are exec.approval.resolve (to answer a card) and exec.approvals.pending (to enumerate open cards).
See Also
- Methods Reference -- All currently registered namespaces
- chat.* -- The transport that the model uses
- clarification.* -- The
ask_usersister surface (same exec-tier gate family)