Paperclip
Paperclip can strand a human comment on a sibling issue after the agent run ends
A Paperclip patch traces deferred human-comment wakes that remain parked forever when a run held more than its primary issue. Finalization drains only the primary queue, while the recovery reconciler mistakes the stranded row for an active execution path.
paperclipai/paperclip PR #10270 is the inspected primary source: “fix(server): promote deferred wakes for every issue a finalizing run held, not just the primary.” The patch starts from Paperclip’s wake contract: a user comment arriving while an assignee is already running is deferred, then promoted when the run finalizes. A single run can hold execution or checkout locks on several issues, and cleanup already iterates those candidates, but releaseIssueExecutionAndPromote drains deferred rows for only the context or primary issue. A comment on a held sibling therefore stays at deferred_issue_execution after the run succeeds. Worse, the recovery reconciler sees that row and concludes an execution path still exists, so it declines to rescue the issue. The patch extracts the existing drain body, applies it to eligible siblings, and adds regressions for ordinary finalization and a primary lock repointed to a retry.
The facts
- paperclipai/paperclip PR #10270 was created 2026-07-25T22:22:09Z and updated 2026-07-26T00:21:25Z; state is open. - paperclipai/paperclip returned 74738 GitHub stars, 4947 open issues, default branch master, and last push 2026-07-25T17:46:10Z. - Latest tagged-release baseline checked: v2026.722.0 published 2026-07-22T23:05:41Z. - The patch starts from Paperclip’s wake contract: a user comment arriving while an assignee is already running is deferred, then promoted when the run finalizes. - A single run can hold execution or checkout locks on several issues, and cleanup already iterates those candidates, but releaseIssueExecutionAndPromote drains deferred rows for only the context or primary issue. - A comment on a held sibling therefore stays at deferred_issue_execution after the run succeeds. - Worse, the recovery reconciler sees that row and concludes an execution path still exists, so it declines to rescue the issue. - The patch extracts the existing drain body, applies it to eligible siblings, and adds regressions for ordinary finalization and a primary lock repointed to a retry.
What changed
The patch starts from Paperclip’s wake contract: a user comment arriving while an assignee is already running is deferred, then promoted when the run finalizes. A single run can hold execution or checkout locks on several issues, and cleanup already iterates those candidates, but releaseIssueExecutionAndPromote drains deferred rows for only the context or primary issue. A comment on a held sibling therefore stays at deferred_issue_execution after the run succeeds. Worse, the recovery reconciler sees that row and concludes an execution path still exists, so it declines to rescue the issue. The patch extracts the existing drain body, applies it to eligible siblings, and adds regressions for ordinary finalization and a primary lock repointed to a retry. The primary record was inspected with its timestamps, state, body, and adjacent project records. ClawCharts supplied the assignment list; it does not establish the claim.
Why it matters
A deferred wake is a promise that a human instruction will be delivered later. Leaving the row durable while suppressing both delivery and recovery is a particularly deceptive failure: the database looks busy, the agent is idle, and the user receives no error. Multi-issue runs make this an orchestration integrity problem rather than a comment feature bug. The operational test is whether persisted state, visible control, and runtime behavior agree at the handoff where authority changes.
Current
PR #10270 was open with 13 focused tests, 169 adjacent tests, and TypeScript checks reported green. The author explicitly notes a residual edge: if two or more non-primary siblings each hold deferred wakes, the helper returns after the first promotion. Paperclip’s latest tagged baseline was v2026.722.0; no inspected release contains this candidate. Repository metadata, current issues and pull requests, release baseline, Hacker News discovery, and the rendered ranking row were checked. Weak search residue and historically used source spines were not promoted.
Evidence
The primary URL is https://github.com/paperclipai/paperclip/pull/10270. Supporting links are inspected current project records that establish implementation, adjacent direction, or boundary conditions. Dates, reproductions, test totals, and deployment observations remain attributed to their authors unless this brief explicitly says they were independently rerun.
Source boundary
Open work is described as open, merged work as merged, and operator reports as reports. A closed issue or passing branch test is not silently translated into a released fix. Ranking explains why the project was scanned; it does not prove correctness, adoption, or package behavior.
Operator take
Reproduce with one run holding issue A and sibling B, comment on B during execution, and follow the persisted wake through finalization. Closure requires one queued run or an explicit terminal rejection; a lingering deferred row must not count as a healthy execution path. Preserve a before-state receipt and verify the narrowest invariant where state changes. Do not broaden permissions or delete state merely because the visible symptom is inconvenient.
Caveat
Public project records are mutable. Source state was captured at publication time, and later revisions may change status, scope, or evidence. No source here authorizes automatic mutation of a reader’s deployment.
Source inspected; source state, environment, and release boundary remain explicit.