## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Sandbox-provider plugins (cloudflare, daytona, e2b, exe-dev, kubernetes, modal, novita) and `plugin-workspace-diff` are published as standalone npm packages, but during local dev they need the in-repo `@paperclipai/plugin-sdk` symlinked in > - Each of these plugins shipped a `postinstall` lifecycle script that traversed *out* of its own package directory (`node ../../../../scripts/link-plugin-dev-sdk.mjs`) to do that linking > - The publishable manifest is built by a `prepack` whitelist that drops the `scripts` field, so npm consumers don't see the postinstall today — but that safety property depends entirely on `prepack` running on every publish. A publish that skips lifecycle scripts would ship a tarball whose postinstall escapes its package directory at consumer install time > - This pull request removes the escape-the-package-dir lifecycle script from every plugin source manifest and moves the dev linking to a single root-level postinstall that iterates the excluded plugin directories itself > - The benefit is that plugin tarballs can no longer carry an install-time script that reaches outside their own directory, regardless of whether `prepack` runs ## Linked Issues or Issue Description This is a follow-up hardening change flagged during review of the Novita sandbox provider PR (#7595). **Problem (security):** Excluded plugin packages each carried `"postinstall": "node ../../../../scripts/link-plugin-dev-sdk.mjs"`. The relative path traverses outside the package root. Today the published manifest is sanitized by a `prepack` whitelist that drops `scripts`, so consumers are unaffected in the normal publish path. The risk is that this is a defense-in-depth gap: if a publish ever skips lifecycle scripts (e.g. `npm publish --ignore-scripts` is *not* used, or a tool publishes the raw manifest), the tarball would ship a postinstall that runs out-of-tree code at the consumer's install time. ## What Changed - Added a single root `package.json` `postinstall`: `node scripts/link-plugin-dev-sdk.mjs`. - Rewrote `scripts/link-plugin-dev-sdk.mjs` to iterate the excluded plugin directories itself (`packages/plugins/sandbox-providers/*` + the orchestration smoke example) instead of relying on each plugin to invoke it from its own cwd. Preserves both prior behaviors: leave a real installed SDK dir alone, and skip when already correctly symlinked (idempotent). - Removed `scripts.postinstall` from all 7 sandbox-provider plugins (cloudflare, daytona, e2b, exe-dev, kubernetes, modal, novita). - Removed `scripts.postinstall` from `plugin-workspace-diff` (a pnpm workspace member — pnpm already links the SDK, so the script was a no-op there). ## Verification - `node scripts/link-plugin-dev-sdk.mjs` from repo root: links the SDK into the excluded plugins and reports skipped (already-linked) dirs; re-running is idempotent. - `grep -r "link-plugin-dev-sdk" packages/plugins/*/package.json packages/plugins/sandbox-providers/*/package.json` returns no matches — no plugin source manifest references the linker any longer. - All affected `package.json` files re-validated as parseable JSON. ## Risks Low risk. Dev-only tooling: the linker only runs at the repo root during local install and only touches `node_modules/@paperclipai/plugin-sdk` symlinks inside excluded plugin dirs. No change to published plugin behavior or runtime code. Worst case if the root postinstall failed to run, local dev of an excluded plugin would not find the SDK symlink — easily re-run manually. ## Model Used Claude Opus (claude-opus-4-8), extended reasoning, with tool use / code execution in an agentic coding harness. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues OR (b) described the issue in-PR following the relevant issue template - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable (added `scripts/link-plugin-dev-sdk.test.js`, wired into `test:release-registry`) - [ ] If this change affects the UI, I have included before/after screenshots (N/A — no UI change) - [ ] I have updated relevant documentation to reflect my changes (N/A) - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>
@paperclipai/plugin-modal
First-party Modal sandbox provider plugin for Paperclip.
Like the other sandbox-provider packages in this repo, it lives inside the Paperclip monorepo but is intentionally excluded from the root pnpm workspace and shaped to publish and install like a standalone npm package. That lets operators install it from the Plugins page by package name without introducing root lockfile churn for Modal's SDK dependencies.
Install
From a Paperclip instance, install:
@paperclipai/plugin-modal
The host plugin installer runs npm install into the managed plugin directory, so the modal SDK dependency is pulled in during installation.
Runtime support note
Modal's official JS SDK README pins support to Node 22 or later. Paperclip's repo baseline is currently node >= 20; empirically modal@0.7.4 imports and operates against the Modal API under Node 20, so the plugin runs there today, but the vendor support contract is Node 22+. The plugin logs a startup warning when it detects Node < 22. Operators who can pin their Paperclip runtime to Node 22+ should do so; treat Node-20 usage as best-effort until the host bumps its baseline.
The empirical Node 20 compatibility check is recorded in PAPA-352.
Configuration
Configure Modal from Company Settings -> Environments, not from the plugin's instance settings page.
| Field | Required | Description |
|---|---|---|
appName |
yes | Modal App name. The plugin calls modal.apps.fromName(appName, { createIfMissing: true }), so the App is created on first acquire if it does not already exist. |
image |
yes | Container image passed to modal.images.fromRegistry(), e.g. python:3.13 or node:20. |
tokenId / tokenSecret |
yes | Modal auth tokens. Both must be provided together. Paperclip stores pasted values as company secrets. The plugin worker runs in a child process that does not inherit host env vars, so MODAL_TOKEN_ID / MODAL_TOKEN_SECRET set on the Paperclip server are not read by the plugin — provide the tokens in this form. |
environment |
no | Optional Modal environment name. Falls back to the SDK profile default. |
workdir |
no | Remote working directory inside the sandbox. Defaults to /workspace/paperclip. |
sandboxTimeoutMs |
no | Maximum sandbox lifetime in milliseconds. Must be a positive multiple of 1000 between 1000 and 86_400_000 (24 hours). Defaults to 3_600_000 (1 hour). |
idleTimeoutMs |
no | Optional idle timeout in milliseconds. Modal terminates the sandbox if no exec is active for this duration. Must be a positive multiple of 1000. |
execTimeoutMs |
no | Default per-exec timeout in milliseconds when the caller does not pass one. Must be a positive multiple of 1000. Defaults to 300_000 (5 minutes). |
blockNetwork |
no | Block all egress network access. |
cidrAllowlist |
no | List of CIDRs the sandbox may reach. Cannot be combined with blockNetwork. |
reuseLease |
no | When true, the sandbox is detached (not terminated) on release and reattached by id later. Defaults to false. |
Reuse semantics
Modal does not expose a separate pause/resume primitive for sandboxes — there is no equivalent to e2b's pause(). The plugin implements reuseLease as follows:
reuseLease: false(default): On release the sandbox isterminate()d. Subsequent runs create a new sandbox.reuseLease: true: On release the plugin callssandbox.detach(). The sandbox keeps running on Modal until its configuredsandboxTimeoutMsoridleTimeoutMselapses. The next acquire/resume reconnects viamodal.sandboxes.fromId(providerLeaseId). If the sandbox has expired,fromIdraisesNotFoundErrorand the plugin reports the lease as expired so Paperclip reacquires.
Because there is no real pause, reuseLease: true keeps billing running until the sandbox or idle timeout cuts it off. Tune idleTimeoutMs to a value that matches your reuse window.
Local development
cd packages/plugins/sandbox-providers/modal
pnpm install --ignore-workspace --no-lockfile
pnpm build
pnpm test
pnpm typecheck
These commands assume the repo root has already been installed once so the local @paperclipai/plugin-sdk workspace package is available to the compiler during development.
Operator verification
- Provision Modal credentials in your Modal account (
modal token new) or use a service account. - Install the plugin from the Paperclip Plugins page.
- In
Company Settings -> Environments, add a new Modal sandbox environment with at leastappName,image,tokenId, andtokenSecret. - Run the environment Probe action. A success result confirms auth, app creation, image pull, and
execround-trip. - Run at least one Paperclip task with a remote-managed adapter (for example
claude_local) bound to that environment. The adapter should provision the sandbox, run commands in it, and clean it up.
Full end-to-end manual QA is tracked separately in PAPA-354.
Package layout
src/manifest.tsdeclares the sandbox-provider driver metadatasrc/plugin.tsimplements the environment lifecycle hookssrc/worker.tsboots the plugin under the host worker runtimepaperclipPlugin.manifestandpaperclipPlugin.workerpoint the host at the built plugin entrypoints indist/