Paperclip drafts work folders that can outlive the sandbox holding them

Paperclip's work-folder proposal, opened September 7 and restacked against current mainline, makes a sandbox volume explicitly insufficient as the only copy of an agent's work. The draft would save task, agent, responsible-user and project files through object storage, with ownership and current references in Postgres. Repository checkpoints would include work that has not reached a remote Git server. A separate runner-recovery change merged early September 13, but it does not make the draft persistence layer available. The distinction is between recovering an execution and recovering its working material when the original environment is gone.

The facts

- The draft shares one persistence lifecycle across legacy adapters and native sandbox execution, with a 180-second periodic save interval. - Scoped folders are placed beneath the sandbox's actual home rather than copying a person's entire computer home. - Files and repository checkpoint content go through object storage; Postgres holds ownership, current references, trash and sync state. - Final-save failures retain the sandbox so the only remaining working copy is not discarded. - Earlier staging evidence reports recovery of saved files, unpushed commits, index state, tracked edits and untracked files after the original sandbox and app volume were unavailable. - The latest draft explicitly awaits final staging acceptance; linked worktrees and submodules are unsupported, and overwritten scoped-file history is not retained.

Why it matters

Persistent agents need more than a process that restarts. A usable recovery must restore the right task's files without leaking another user's private material or discarding unpublished edits. Paperclip's approach separates durable content from disposable execution, but introduces a larger identity and conflict-resolution surface. The current recovery work illustrates the other half of the problem: a warm provider session must keep its owner, messages and outcome even when the app controller changes.

Current

Inspected on 2026-09-13. The Paperclip release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.

Evidence

Primary evidence: paperclipai/paperclip PR #13002 (https://github.com/paperclipai/paperclip/pull/13002). Supporting context: paperclipai/paperclip PR #13338 (https://github.com/paperclipai/paperclip/pull/13338); Paperclip — official product README (https://raw.githubusercontent.com/paperclipai/paperclip/master/README.md). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.

Operator take

Judge the proposed system by loss scenarios rather than the presence of a save icon. Remove the original disposable sandbox in an authorized test, make the application volume unavailable and verify object-only restoration of repository state. Also force a final-save failure and confirm the remaining copy survives. The draft reports earlier demonstrations of these paths, but says they do not establish acceptance of its newest restacked head. Shared-file conflict behavior deserves explicit user-facing explanation.

Caveat

This is an open draft, not an available storage guarantee. Current-head configuration and browser acceptance remain pending. Earlier staging results are revision-scoped. Last-write-wins shared files do not provide overwritten-file history, and repository checkpoints currently exclude linked worktrees and submodules; merged runner recovery does not remove those limits.