mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-06 21:05:21 +02:00
Devin FoleyandPaperclip
7a5a217d60
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip can run an agent in a remote-managed environment, such as a sandbox provider or an SSH host. > - The server resolves an execution target for each run. The resolver kept its own hardcoded list of allowed adapters. > - The shared capability metadata in `packages/shared/src/environment-support.ts` already defines which adapters support remote-managed environments. The environment selector and the capabilities API use it. > - The two lists drifted. The UI offered sandbox environments to Grok Build (`grok_local`) agents, but the resolver refused them at run time. > - This pull request makes the resolver use the shared capability check for both the sandbox gate and the SSH gate. > - The benefit is one source of truth. The UI and the runtime now agree on which adapters can use remote-managed environments. ## Linked Issues or Issue Description No public GitHub issue exists for this bug. Inline description per the bug report template: **What happened?** A Grok Build (`grok_local`) agent was assigned a sandbox environment (a Daytona provider). The UI allowed the assignment. Every run and primary-model test then failed with the warning: `Adapter "grok_local" is not allowed in "<environment>" environments.` **Expected behavior** An adapter that the environment selector offers for a sandbox environment must also pass the runtime gate. The Grok Build run must start in the sandbox. **Steps to reproduce** 1. Create a sandbox environment (for example, with a Daytona provider plugin). 2. Create an agent that uses the `grok_local` adapter. 3. Set the agent's environment to the sandbox environment. The UI accepts this. 4. Run the agent, or run the primary-model test. The run fails with the adapter-not-allowed warning. **Paperclip version or commit** Reproduced on `master` at `0edb742f8d`. **Deployment mode** Local instance with a remote sandbox provider plugin. The same gate also applies to SSH environments. ## What Changed - `resolveEnvironmentExecutionTarget` in `server/src/services/environment-execution-target.ts` now gates the sandbox path with the shared `adapterSupportsRemoteManagedEnvironments()` helper. Before, it used a hardcoded six-adapter list that did not include `grok_local`. - The SSH path in the same file now uses the same shared helper. - New regression tests in `server/src/__tests__/environment-execution-target.test.ts`: sandbox target resolution for every remote-managed adapter (including `grok_local`), SSH target resolution for `grok_local`, and the null path for an adapter without remote-managed support. ## Verification - Run `node_modules/.bin/vitest run server/src/__tests__/environment-execution-target.test.ts`. All 10 tests pass, including the 3 new ones. - Confirm `grok_local` is in the `REMOTE_MANAGED_ADAPTERS` set in `packages/shared/src/environment-support.ts`. The resolver now reads the same set. - On a live local instance with this fix, a `grok_local` agent assigned to a Daytona sandbox environment no longer produces the adapter-not-allowed warning. ## Risks Low risk. The change routes two hardcoded checks through existing shared capability metadata. Behavior changes only where the lists had drifted: `grok_local`, and any future adapter added to the shared set, can now resolve sandbox and SSH execution targets. Adapters outside the shared set still return `null`. ## Model Used Claude Fable 5 (`claude-fable-5`) by Anthropic, with extended thinking and tool use, running in Claude Code. ## 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 - [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 Co-authored-by: Paperclip <noreply@paperclip.ing>