2 Commits

Include renames

Author	SHA1	Message	Date
Devin Foley	9f5af4ea5d	fix(server): accept secret_ref binding objects in sandbox provider environment config (#10355) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents execute in environments; sandbox provider plugins (Daytona, Modal, e2b, …) declare their config via a JSON schema, with credentials marked `format: "secret-ref"` > - The environments UI renders those fields with a secret picker that submits `{ type: "secret_ref", secretId, version }` binding objects, while the server-side environment config paths only understood raw string values and bare secret-id strings > - The binding object reached the plugin worker's `environmentValidateConfig` untouched; plugins parse non-string config values as absent, so saving or testing an environment with a picker-bound secret always failed validation (e.g. "Daytona sandbox environments require an API key in config or DAYTONA_API_KEY.", "Modal sandbox environments require tokenId and tokenSecret.") > - Worse, an environment first saved with raw pasted values becomes uneditable: the stored value is a secret reference, the edit form re-submits it as a binding object, and every subsequent save fails the same way > - This pull request canonicalizes binding objects to the bare secret id before plugin validation, and teaches the persistence/runtime/probe secret-ref resolvers to accept the object shape defensively > - The benefit is that picker-bound secrets work for every schema-driven sandbox provider — create, edit, and Test — with no plugin changes required ## Linked Issues or Issue Description Fixes #10105 The same failure reproduces with the Daytona provider: Settings → Instance settings → Environments → New, driver sandbox, provider daytona, bind Api Key to an existing secret via the picker → Save fails with "Daytona sandbox environments require an API key in config or DAYTONA_API_KEY." ## What Changed - `server/src/services/json-schema-secret-refs.ts`: new `parseSecretRefBindingObject()` that recognizes the `{ type: "secret_ref", secretId, version? }` shape the secret picker submits (version defaults to `"latest"`; malformed objects return null). - `server/src/services/plugin-environment-driver.ts`: `validatePluginSandboxProviderConfig()` now canonicalizes binding objects at the driver schema's `format: "secret-ref"` paths to the bare secret id (the persisted shape) before invoking the plugin worker's `environmentValidateConfig`. Pinned numeric versions are rejected with a clear 422, since sandbox provider references always resolve the latest version — silently resolving a different version would be worse. - `server/src/services/environment-config.ts`: the persistence, runtime, and probe secret-ref resolvers plus `collectEnvironmentSecretRefs()` accept the binding-object shape defensively, so any previously persisted object-shaped refs (from providers whose validation tolerated them) resolve instead of being silently skipped; the missing-companyId runtime guard also now fails closed for object-shaped refs. ## Verification - `npx vitest run server/src/__tests__/json-schema-secret-refs.test.ts server/src/__tests__/plugin-sandbox-provider-config-validation.test.ts server/src/__tests__/environment-routes.test.ts server/src/__tests__/environment-config.test.ts` — 82 tests pass, including new coverage: binding-object canonicalization before plugin validation, pinned-version rejection, raw-string pass-through, and a route-level create with a picker-submitted binding object persisting the bare secret id without minting a duplicate secret. - `npx vitest run server/src/__tests__/environment-runtime.test.ts` — 24 tests pass against embedded Postgres, including a new test that persists an object-shaped ref and verifies runtime resolution produces the plaintext credential for the plugin worker. - `pnpm typecheck` in `server/` — clean. ## Risks - Low. The canonical persisted shape (bare secret-id string) is unchanged, so existing saved environments and lease-resume fingerprints are unaffected; raw pasted values and bare-id strings take exactly the same code path as before. - New behavior only triggers where a save/probe previously failed 422 (binding objects at secret-ref paths) or where an object-shaped ref was previously skipped silently at runtime (now resolved, or failed closed without a companyId). - Pinned binding versions at sandbox-provider paths are now an explicit 422 instead of an accidental validation failure; no UI submits pinned versions today (`allowVersionSelector={false}`). ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and agentic tool use (Claude Code harness): source diagnosis, fix, and tests. ## 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 with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no doc surface changed) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-07-28 10:50:13 -07:00
Devin Foley	5bd0f578fd	Generalize sandbox provider core for plugin-only providers (#4449) ... ## Thinking Path > - Paperclip is a control plane, so optional execution providers should sit at the plugin edge instead of hardcoding provider-specific behavior into core shared/server/ui layers. > - Sandbox environments are already first-class, and the fake provider proves the built-in path; the remaining gap was that real providers still leaked provider-specific config and runtime assumptions into core. > - That coupling showed up in config normalization, secret persistence, capabilities reporting, lease reconstruction, and the board UI form fields. > - As long as core knew about those provider-shaped details, shipping a provider as a pure third-party plugin meant every new provider would still require host changes. > - This pull request generalizes the sandbox provider seam around schema-driven plugin metadata and generic secret-ref handling. > - The runtime and UI now consume provider metadata generically, so core only special-cases the built-in fake provider while third-party providers can live entirely in plugins. ## What Changed - Added generic sandbox-provider capability metadata so plugin-backed providers can expose `configSchema` through shared environment support and the environments capabilities API. - Reworked sandbox config normalization/persistence/runtime resolution to handle schema-declared secret-ref fields generically, storing them as Paperclip secrets and resolving them for probe/execute/release flows. - Generalized plugin sandbox runtime handling so provider validation, reusable-lease matching, lease reconstruction, and plugin worker calls all operate on provider-agnostic config instead of provider-shaped branches. - Replaced hardcoded sandbox provider form fields in Company Settings with schema-driven rendering and blocked agent environment selection from the built-in fake provider. - Added regression coverage for the generic seam across shared support helpers plus environment config, probe, routes, runtime, and sandbox-provider runtime tests. ## Verification - `pnpm vitest --run packages/shared/src/environment-support.test.ts server/src/__tests__/environment-config.test.ts server/src/__tests__/environment-probe.test.ts server/src/__tests__/environment-routes.test.ts server/src/__tests__/environment-runtime.test.ts server/src/__tests__/sandbox-provider-runtime.test.ts` - `pnpm -r typecheck` ## Risks - Plugin sandbox providers now depend more heavily on accurate `configSchema` declarations; incorrect schemas can misclassify secret-bearing fields or omit required config. - Reusable lease matching is now metadata-driven for plugin-backed providers, so providers that fail to persist stable metadata may reprovision instead of resuming an existing lease. - The UI form is now fully schema-driven for plugin-backed sandbox providers; provider manifests without good defaults or descriptions may produce a rougher operator experience. ## Model Used - OpenAI Codex via `codex_local` - Model ID: `gpt-5.4` - Reasoning effort: `high` - Context window observed in runtime session metadata: `258400` tokens - Capabilities used: terminal tool execution, git, and local code/test inspection ## 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 run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge	2026-04-24 18:03:41 -07:00