Paperclip
Paperclip can run two agents inside one issue worktree
A Paperclip report says the dispatcher marks a queued run active before checking the issue execution lock, then ignores a zero-row lock update. Two runs can enter the same issue-keyed worktree, move HEAD under each other and make a supposed red-before-green test pass against already-modified code.
paperclipai/paperclip issue #9447 is the inspected primary source: “Dispatcher ignores the issue execution lock: a queued run whose issue already has a live run is claimed and executed anyway (concurrent worktree race → false-green test proofs).” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- paperclipai/paperclip issue #9447 was created 2026-07-12T13:08:01Z and was open at inspection; its title is “Dispatcher ignores the issue execution lock: a queued run whose issue already has a live run is claimed and executed anyway (concurrent worktree race → false-green test proofs).” - paperclipai/paperclip PR #10520 was created 2026-07-30T22:20:51Z and was closed at inspection; its title is “fix(worktree): disable automatic database backups.” - paperclipai/paperclip issue #10525 was created 2026-07-30T23:29:19Z and was open at inspection; its title is “process-session-remote.mjs leaks: PID captured but discarded on spawn, never killed on stop().” - The repository reported 75210 stars, 5026 open issues, default branch master, and last push 2026-07-31T00:47:08Z. - The latest tagged-release baseline checked was v2026.722.0 published 2026-07-22T23:05:41Z.
What changed
paperclipai/paperclip issue #9447 reports: Summary claimQueuedRun flips a queued run to running **before** it tries to take the issue's execution lock, and the lock-taking UPDATE is a *conditional* update whose zero-row result is never checked. When another live run already holds issues.executionRunId, the stamp silently no-ops — and the second run is dispatched and executed anyway. Because the execution branch/worktree is keyed by **issue** (not by run), both runs then land in the *same* git worktree. In our case two runs of the same agent on the same issue raced: one run's HEAD moved
paperclipai/paperclip PR #10520 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Paperclip creates isolated instances for linked git worktrees so development does not affect the primary instance - Those instances inherited the source instance's automatic database-backup setting and also repaired older configs without overriding it - As worktrees accumulated, each isolated instance could schedule its own backup stream, producing redundant backup churn for disposable database clones - This pull request makes backup disablement an invariant of worktree config creation and repair - The
paperclipai/paperclip issue #10525 reports: Summary startAdapterExecutionTargetProcessSessionBridge in packages/adapter-utils/src/execution-target.ts spawns the remote session daemon with nohup node paperclip-process-session-remote.mjs... >/dev/null 2>&1 [])), so when sessionDir is deleted the remote process continues to loop indefinitely rather than exiting. Sending SIGTERM is the reliable kill path; relying on directory-removal to stop the process is inherently racy. Workaround (applied locally) One-time reap of the 63 non-gated sessions: SIGTERM was sufficient — all 63 exited cleanly with no SIGKILL needed.
Why it matters
Concurrency bugs that falsify verification are worse than ordinary merge conflicts because the receipt remains green. Lock acquisition and run-state transition must be one transaction at the claim boundary. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.
Current
The primary record was open when captured on 2026-07-31. The release baseline was v2026.722.0 published 2026-07-22T23:05:41Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/paperclipai/paperclip/issues/9447. Supporting records are https://github.com/paperclipai/paperclip/pull/10520 and https://github.com/paperclipai/paperclip/issues/10525. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly 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. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Fail the claim when another live run owns the issue, preserve issue-keyed worktrees for continuation, and treat per-agent concurrency limits only as a temporary workaround. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
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.