Open Science keeps humans in the loop by pausing agent execution whenever a tool call requires explicit approval. When the agent attempts a tool call that needs confirmation, execution halts and a permission request card appears inline above the composer in the conversation panel. The agent waits until you respond before proceeding.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/aipoch/open-science/llms.txt
Use this file to discover all available pages before exploring further.
How Permissions Work
When the agent wants to use a tool that requires confirmation, theAcpPermissionBroker receives a requestPermission call from the ACP runtime. The broker assigns a unique requestId, stores the pending request, and emits it to the renderer via an IPC event. The conversation panel picks up the pending request and renders an approval card.
The agent’s execution is suspended — the Promise returned by requestPermission does not resolve until the renderer calls respond with either a chosen optionId or a cancellation signal.
Permission Request Structure
Each pending request exposed to the UI is anAcpPermissionRequest:
| Field | Type | Description |
|---|---|---|
requestId | string | Unique identifier assigned by the broker when the request was created |
sessionId | string | The ACP session whose execution is paused awaiting this decision |
toolCallId | string | The specific tool call from the agent that triggered the request |
title | string | Human-readable description of the action being requested |
status | string? | Optional status string provided by the tool call |
options | AcpPermissionOption[] | One or more choices the user can make (see below) |
raw | unknown | The complete original RequestPermissionRequest from the ACP SDK |
options array is an AcpPermissionOption with these fields:
| Field | Type | Description |
|---|---|---|
optionId | string | Opaque identifier sent back to the broker when this option is chosen |
name | string | Display name shown on the button (overridden by the UI for known kinds) |
kind | string | Protocol semantic: allow_always, allow_once, reject_always, reject_once, or a custom string |
Approval Card UI
Permission request cards are rendered above the composer in an amber-colored card. Each card shows thetitle of the request and a row of option buttons. Buttons are sorted in a fixed order — Always first, then Allow once, then Reject, then any custom options.
The display labels for standard option kinds are normalized by the UI regardless of the raw name field:
kind | Button label |
|---|---|
allow_always | Always |
allow_once | Allow once |
reject_always | Reject |
reject_once | Reject |
| anything else | The raw name from the option |
Responding to a Permission Request
Review the request
Read the
title displayed in the amber card to understand what action the agent is asking to perform. For full transparency, the card also carries the raw tool call details in the raw field, accessible via developer tools.Choose an option
Click one of the option buttons (e.g. Always, Allow once, Reject) to approve with that choice. The broker resolves the pending Promise with
outcome: 'selected' and the chosen optionId, and the agent resumes execution.Cascading Cancellation
TheAcpPermissionBroker handles two teardown scenarios automatically:
- Session deleted:
cancelForSession(sessionId)cancels every pending request associated with that session while leaving other sessions’ pending requests intact. - Full runtime shutdown:
cancelAll()cancels every pending request across all sessions.
outcome: 'cancelled', allowing the runtime to clean up gracefully.