Paperclip merges task-level connection reviews with durable continuation

Paperclip merged a task-level connection review flow early on September 9, following the previous day's native-task service setup work. The combined direction is to keep the request for access, the human decision and the resumed agent inside one task history. It is not simply a new approval button: both task cards and the Connections queue are intended to resolve the same server-owned request, then continue the originating work through a durable receipt.

The facts

- PR 13063 was merged on September 9; its companion connection-setup PR 13058 was merged on September 8. - The review card offers Decline and Approve & run, with Always allow in a split-button menu and a pending record retained after dismissal. - Human decisions share one transaction preserving signed arguments, expiry, context binding and formal approval requirements. - A durable delivery table and unique wake claim support restart recovery without automatically replaying an uncertain provider call. - Remembered permission is scoped to the same agent, connection, action and current project; it is broader than permission for only one exact argument set.

Why it matters

Agent work often stops at a missing connection, then loses its context while a person navigates elsewhere to authorize it. Bringing setup and review into the task can reduce that interruption without granting the agent authority to approve itself. The scope of remembered permission deserves attention: future arguments are permitted within the saved action scope, while revocation and formal approval gates still apply. Operators should understand that difference before turning a one-time request into standing access.

Current

Inspected on 2026-09-09. The Paperclip stable-release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was merged 2026-09-09T00:37:14Z when captured. Release metadata is a version boundary; an open proposal, a merged mainline change and a packaged release remain different states.

Evidence

The primary evidence is paperclipai/paperclip PR #13063 (https://github.com/paperclipai/paperclip/pull/13063). Supporting context comes from paperclipai/paperclip PR #13058 (https://github.com/paperclipai/paperclip/pull/13058); Paperclip — Connected Apps and approval roadmap (https://raw.githubusercontent.com/paperclipai/paperclip/master/ROADMAP.md). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

For a staging upgrade, follow a task from missing access to approval, restart the service around result delivery, and verify that only the intended task resumes. Also test decline, changed ownership and an uncertain provider outcome. The companion setup flow starts a fresh provider session after access becomes ready, which is relevant when an old session still has an outdated tool inventory. Check migration timing on larger installations: the new unique wake index can briefly block writes. A merged branch is a source milestone, not proof that every deployed release already contains the flow.

Caveat

The inspected review record reports five deterministic browser journeys and a real native Codex run against a local MCP fixture. Live Notion and the complete model-runner matrix remained unverified. Fixture completion is not universal provider acceptance, and a database decision cannot make a remote side effect exactly once.