Paperclip users ask to keep SSH work in the developer’s checkout

The request exposes a mismatch between a shared task board and a developer’s actual working surface. A frontend agent can finish successfully in a staged directory while the editor and preview server remain attached to a different checkout. Copy exclusions can save network traffic, but they do not solve that authority mismatch. The requester wants local review before a commit or pull request, without running a separate control plane on every workstation.

The proposed acceptance criteria are deliberately narrower than ‘support SSH’. They ask for an operator-selected root, no workspace upload or restore in in-place mode, persistent dependencies, explicit shared-root concurrency and logs naming the authoritative machine and path. Unsupported adapter combinations must fail clearly. The existing workspace contract supplies vocabulary for copy versus in-place realization; the report asks whether there is already a supported driver route before proposing another local patch.

The facts

- Issue #12910 was filed September 5 and describes a Linux control plane dispatching Codex work to macOS over SSH. - The report says standard SSH execution uses per-run copy and restore, potentially moving dependency trees along with source. - Its proposed in-place mode keeps copy as the default and requires an explicitly selected authoritative remote root. - A disposable two-run experiment reportedly preserved a 1GiB sparse dependency fixture’s inode and size; the author explicitly rejects treating this as a throughput benchmark. - Related PR #12907 bounds managed GitHub identity projection and restricts outer-sandbox authority to managed sandbox transports, not local or SSH execution.

Why it matters

This is adoption friction at the boundary between centralized orchestration and personal development tools. Keeping the board shared does not imply that every worktree must move to a server. But executing in a live checkout also removes the disposable-copy buffer: concurrent edits, local uncommitted work and credential ownership become operational obligations. The related GitHub-projection change illustrates why transport identity and workspace placement must remain separate decisions.

Current

Inspected on 2026-09-06. The Paperclip stable-release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is paperclipai/paperclip issue #12910 (https://github.com/paperclipai/paperclip/issues/12910). Supporting context comes from Paperclip docs — isolated workspaces (https://docs.paperclip.ing/experimental/isolated-workspaces/); paperclipai/paperclip PR #12907 (https://github.com/paperclipai/paperclip/pull/12907). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Use the report as a design review, not a recommendation to patch a production driver. Compare persistent-root locking, unsupported adapters and recovery after disconnection before measuring transfer savings. The limited experiment reports roughly 0.2MB of managed Codex-home material staged per run, but that is not the whole workload’s performance. Preserve copy mode for disposable jobs and require an explicit opt-in when the agent will edit the directory a person is actively using.

Caveat

The feature request remained open and supplies feasibility evidence for Codex only, not cross-adapter or multi-user readiness. The supporting GitHub-identity PR was closed at inspection; that alone does not establish release inclusion. Official workspace documentation is current context, not a newly dated announcement.