Paperclip
Paperclip freezes review policy after terminal work
Paperclip proposes freezing managed review instructions against later mutation, failing closed when a completed issue receives another heartbeat, and notifying the unblock owner on every transition that leaves work blocked.
paperclipai/paperclip PR #11988 is the inspected primary source: “fix(server): freeze review policy against managed instruction mutation.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- paperclipai/paperclip PR #11988 was created 2026-08-22T23:08:13Z and was open at inspection; its title is “fix(server): freeze review policy against managed instruction mutation.” - paperclipai/paperclip PR #11987 was created 2026-08-22T22:27:22Z and was open at inspection; its title is “fix(heartbeat): fail closed after issues reach done.” - paperclipai/paperclip PR #11982 was created 2026-08-22T21:36:40Z and was open at inspection; its title is “fix(issues): notify the unblock owner on every path that leaves an issue blocked.” - The repository reported 79186 stars, 5269 open issues, default branch master, and last push 2026-08-23T00:30:49Z. - The latest tagged-release baseline checked was v2026.817.0 published 2026-08-18T03:17:29Z.
What changed
paperclipai/paperclip PR #11988 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Agent runs load managed instruction files such as AGENTS.md at heartbeat time - A repair task can rewrite those files while a Review is still active - That rewrite can drop required provenance and repository-access gates - This pull request mediates every managed-instruction write during an active Review and pins the Review policy on the run - The benefit is that a later instruction edit cannot relax the gates that the Review started with Linked Issues or Issue Description Describe the bug** An issue-scoped repair can change a reviewer's managed instructions during an active Review. The later Review run then follows the weaker file and can approve without trusted source provenance and without required repository access. Expected behavior** Managed instruction writes fail while the target agent has an active Review. The Review run uses the policy that was pinned at Review start. Steps to reproduce** 1. Start an independent Review that requires trusted sourceTrust and repositoryAccessRequired: true. 2. From another issue, rewrite the reviewer's managed AGENTS.md to add an exception. 3. Resume the Review. The reviewer can now treat the weaker file as authority. Paperclip version** Current master (cc42a67). Related public PRs (not duplicates of this gate): #10975 preserve managed instruction drift
paperclipai/paperclip PR #11987 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Heartbeat dispatch, issue checkout, and stranded-run recovery share the issue execution lock - After an issue reaches done, a later queued or late-finishing automation run can still start - That run can check the issue out again, and recovery can then move it to blocked with no blockers - This pull request fails closed on terminal issues so later runs cannot reopen or regress them - The benefit is that completed work stays complete unless a real resume path reopens it first Linked Issues or Issue Description No public GitHub issue exists for this bug. Related open PRs: Refs #10991, Refs #8134, Refs #8703, Refs #6163. What happened?** After an issue transitions to done, a later automation run can still start. The run can check the issue out and reopen it to in_progress. Stranded-run recovery then moves the issue to blocked with an empty blocker list. Expected behavior** After an issue reaches done or cancelled, later queued or late-finishing runs must fail closed. They must not check out the issue. They must not change its terminal status. Recovery must restore done if checkout already reopened a completed issue. Steps to reproduce** 1. Mark an assigned issue done in one heartbeat run. 2.
paperclipai/paperclip PR #11982 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - The issues subsystem lets a blocked issue record an unblockDescriptor: the agent who owns the way out, and the action they must do - When that descriptor names an agent, the server wakes that agent so the block becomes routable work instead of a dead row - That wakeup was wired to one path only: the moment an issue moves into blocked. Two other paths reach the same state and stayed silent - This pull request calls the same notify step from every path that can leave an issue blocked with an agent-owned descriptor - The benefit is that a blocked issue with a named owner always tells that owner, so blocked work stops being invisible to the person who can clear it Linked Issues or Issue Description No public issue exists for this. The problem follows the bug report template. What happened?** A blocked issue can name an agent as its unblock owner. The server is supposed to wake that agent. It only does so when the issue *enters* blocked through PATCH /api/issues/:id. Two other paths reach the same state and send nothing: 1. **Descriptor attached after the transition.** An issue moves to blocked with blockers and no descriptor. A later
Why it matters
Terminal state and review policy are authority boundaries. Letting mutable instructions or another wake rewrite them turns completed work and blocked ownership into suggestions. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-23. The tagged-release baseline was v2026.817.0 published 2026-08-18T03:17:29Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/paperclipai/paperclip/pull/11988. Supporting records are https://github.com/paperclipai/paperclip/pull/11987 and https://github.com/paperclipai/paperclip/pull/11982. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Snapshot the review contract at admission, reject post-completion wakes, and emit one durable ownership notification for every path that remains blocked. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.