> Review changes. Approve intent. Let agents proceed.
Agents submit structured change requests containing code diffs, configuration updates, or custom values. Humans review and approve them in the browser, then agents verify the platform-signed decision through the API before applying anything.
Agents submit structured change requests containing code diffs, configuration updates, or custom values. Humans review and approve them in a browser UI; agents then verify the platform-signed decision through the API before applying anything. Packaged as a single `docker compose` stack — no infrastructure beyond Postgres required.
│ get_request ─────────────► │ ◄──── signed decision ──────│
│ ◄── state + receipt ─────────│ │
│ consume_approval ─────────► │ mark CONSUMED (single-use) │
│ ◄── receipt (HMAC-SHA256) ───│ │
│ apply changes │ │
```
- **Decisions are platform-signed.** Approvals and rejections carry an HMAC-SHA256 receipt bound to the exact reviewed content (`content_hash`). If the agent changes anything after approval, the receipt no longer matches.
- **Approvals are single-use.** An agent must `consume` an approval before proceeding; it cannot be replayed.
- **Two ways in for agents:** a REST API (`/v1/...`) and an MCP server (`/mcp`), both authenticated with a per-agent API key and backed by the same service layer.
**Key guarantees:**
## Request states
- **Platform-signed decisions.** Every approval and rejection carries an HMAC-SHA256 receipt bound to `content_hash` — the hash of the exact content the human reviewed. If the agent changes anything after approval, the receipt no longer matches.
- **Single-use approvals.** An agent must `consume` an approval before proceeding; the same receipt cannot be replayed.
- **Two integration paths.** Agents connect via a streaming MCP server (`/mcp`) or a plain REST API (`/v1/...`), both authenticated with a per-agent API key and backed by the same service layer.
- **Changes-requested loop.** A human can return a request to the agent with reviewer notes; the agent updates and resubmits, and the updated diff is highlighted in the UI.
No update is possible after approval, rejection, expiry, consumption, or cancellation. A `REQUEST_CHANGES` decision requires a comment and returns the request to the agent, which can `update_request` to resubmit (highlighted in the UI as **UPDATED**).
## Request lifecycle
| State | Meaning |
|---|---|
| `PENDING` | Submitted, awaiting human review |
| `CHANGES_REQUESTED` | Returned to agent with reviewer notes |
| `APPROVED` | Approved; agent must consume before acting |
| `REJECTED` | Hard block; agent must submit a new request |
| `EXPIRED` | Not reviewed within the expiry window |
| `CONSUMED` | Approval used; agent has proceeded |
| `CANCELLED` | Cancelled by agent or human |
No mutation is possible after `APPROVED`, `REJECTED`, `EXPIRED`, `CONSUMED`, or `CANCELLED`.
curl -X POST https://your-host/v1/change-requests/{request_id}/consume -H "x-api-key: pp_agent_..."
```
### Agent instruction
Tell your agent:
> Before taking any consequential action (deploys, config changes, code edits), call `create_request`, wait for approval, then call `consume_approval` before proceeding.
---
## Privacy & data
Humans can export all their data as JSON and delete their account (cascading to agents, requests, and notifications) from **Settings**. Agent icon URLs are fetched once for validation and never stored. See the in-app Privacy Policy and Terms of Service.
- Able to click on a agent either on home, agents list or in a request to show the agents past requests and overall actions from the list but moved over into a new page with a back button to return to the previous page.
- Show QR for 2fa
- invalid dates on admin action notifications
- pre fill data on agent edit modal
- overall ux improvements
- Fix popup for passwordmanagers filling in 2fa code on settings page
- ctrl enter submits modals (all)
- better repo rules for agents
- Nicer statistics on the dashboard
- Instance Notice popup that popups up on every session (like a cookie notice), content by admins, dismissable
- Instance Disabled message & setting for admins to set a message for when the instance is disabled, and a setting to allow users to see the message when the instance is disabled. (users can only delte or download their data when the instance is disabled)
- Data Hoster notice for footer when people host an instance for other people to use, content by admins, not dismissable footer only notice, all pages
@@ -223,6 +223,7 @@ export function SettingsPage() {
<Modal
open={disable2faOpen}
onClose={()=>setDisable2faOpen(false)}
onSubmit={disable2fa}
title="Disable 2FA"
footer={
<>
@@ -246,6 +247,7 @@ export function SettingsPage() {
<Modal
open={deleteOpen}
onClose={()=>setDeleteOpen(false)}
onSubmit={deleteAccount}
title="Delete account"
footer={
<>
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.