Files
PaperClipAI/packages/adapter-utils
Priya RamanandPaperclip de5a1bdbe7 feat(duplex): raise bridge body cap to the API JSON limit and add safety bounds
Raise the sandbox-to-host duplex bridge body cap from 256 KiB to the API JSON
body limit plus one byte (10 MiB + 1). The bridge is a buffering backstop, not
the policy limit, so a body of exactly the API limit passes through and the API
issues its own 413. Fix and bound the change with these parts:

- Add DEFAULT_JSON_BODY_LIMIT_BYTES and derive the "10mb" string from it so the
  byte form and the string form cannot drift. A cross-package test asserts the
  bridge cap equals this byte limit plus one.
- Answer a clean 413 request_too_large, not a retryable 502 with the internal
  message, when a request body passes the bridge cap. readBody throws a typed
  error that each gateway maps to 413.
- Add local in-sandbox body-read admission control. The gateway reserves one
  worst-case body per active read against a process-owned bound and sheds a new
  read with 503 when the bound is full. It releases the reserve on every
  terminal path. This protects the sandbox process; it is separate from the host
  ledger.
- Pin the SSH command output buffer at 1 MiB with its own constant, so it no
  longer tracks the bridge body cap.
- Raise the host pre-bind buffer to 16 MiB, sized from the body cap and the
  base64 body-chunk expansion, so one in-spec body cannot terminate its route.

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-08-23 18:21:06 +00:00
..

@paperclipai/adapter-utils

Shared utilities for Paperclip adapters: process spawning, environment injection, sandbox/SSH transport, workspace sync, and the round-trip helpers that move code between the local execution-workspace cwd and wherever the agent actually runs.

For the adapter-author guide see docs/adapters/creating-an-adapter.md and the in-repo notes at packages/adapters/AUTHORING.md.

No-remote-git contract

The local execution-workspace cwd is the only persistence boundary across runs. No adapter may depend on a git remote for cross-run state.

Adapters that run the agent on a different host should use the SSH round-trip helpers in src/ssh.ts:

  • prepareWorkspaceForSshExecution({ spec, localDir, remoteDir }) — bundles the local cwd (tracked files, dirty edits, untracked additions, and the git history needed to reconstruct it) to remoteDir before the run starts. Runs with no git remote configured.
  • restoreWorkspaceFromSshExecution({ spec, localDir, remoteDir, ... }) — syncs the remote cwd back into localDir after the run, including any new commits the agent created. Also runs with no git remote configured.

prepareRemoteManagedRuntime in src/remote-managed-runtime.ts wraps both calls for adapters that want a per-run remote workspace and an automatic restoreWorkspace() finally hook.

The invariant is pinned by the no-remote-git contract case in src/ssh-fixture.test.ts, which asserts that a remote-only commit propagates to the local worktree through the prepare → restore round-trip with no git remote configured at any point. Do not regress that test.