Decide a pending permission request

POST/v1/threads/{threadId}/permission-requests/{requestId}/decision

Commit an operator decision to the exact runtime approval. Pending decisions do not expire with the runtime transport. Recoverable stopped runs continue through a durable job in the same thread. Retrying the same decision is idempotent; changing a committed decision is a conflict.

How to call this endpoint

Every ACP API request uses bearer authentication. The examples here show the actual request path, auth header, and body shape that the platform expects.

Path, query, and header parameters

These parameters control which ACP object the endpoint acts on and how the request is processed.

Path parameters

Name	Location	Type	Required	Description
threadId	path	string	Yes	Thread ID
requestId	path	string	Yes	—

Query parameters

None.

Body schema

Content type: application/json · Required

Field	Type	Required	Description
decision	allow \| deny	Yes	—
reason	string	No	—

What the API returns

Each response code below includes the documented payload shape for the ACP API.

200Permission decision acceptedapplication/json

Field	Type	Required	Description
ok	boolean	Yes	—
requestId	string	Yes	—
decision	allow \| deny	Yes	—
active	boolean	No	Whether the decision was delivered to a live waiting runtime session.
canonicalMirrored	boolean	No	Whether the ruling and resulting run projection were durably published to Thread v2.
continuation	queued \| delivered \| blocked \| cancelled \| unavailable	No	Delivery state for managed runtime approvals. This does not assert that the tool has executed.
message	string	No	Message text.

400Decision must be allow or deny

None.

403Organization membership or execution scope is missing

None.

404Thread or permission request not found

None.

409A different decision is already committed, or a legacy runtime cannot receive the decision

None.

Decide a pending permission request

Response 200

See the ACP quickstart and SDK flow