d627632874
Docs for parent release `v2026.1106.0` (`d69631b0`), up from `v2026.1023.0` (`1b4c8038`): 515 parent commits. ## How this branch was built The tag is 914 commits behind what `nightly` has drafted, so this branch isn't cut from `nightly` HEAD. It starts at nightly commit `1952052` (parent `043f2514`), 19 commits before the tag, then adds: - the `main` hotfix (#160) - the sync tooling from `nightly` - docs for those 19 commits Later nightly drafts stay on `nightly`, so no pages had to be removed. No `nightly-draft/*` PRs are open. ## What changed - **Runner by default:** new Claude, Codex, OpenCode and Pi agents start on Paperclip Runner on supported hosts, with **Legacy runner** and **Upgrade runner**. - **Workspaces:** cleanup of finished workspaces, optional Git expiration, and restore points for unsaved work. Restore points are off by default. - **New pages:** Prompt injection prevention, Google Workspace, GitHub Copilot, Speko, Braintrust, Daytona, Ditto and Unikraft. - **Breaking and upgrade notes:** the run history limit, Sentry run failures off by default and the DSN variables, the Docker start command for custom images, `--yes` on `instructions-file:delete`, and slower migrations on large instances. - **Also covered:** project repositories as skill sources, roster bulk edit, Artifacts V1 (experimental, off by default), composer dismissal, `expectedStatusVersion`, `unexecuted_review_stage`, and plugin workspace providers. - **Changelog:** a v2026.1106.0 entry in `reference/changelog.md`. ## Older text corrected These were wrong at the tag, and most are also wrong on the live site: - which permissions let an agent read a peer's configuration or change instructions (`api/agents.md`) - `decideNowCount`, which doesn't exist; the field is `deskBadgeCount` - `file-resources` routes, which are board-only - the **Create project** dialog fields, a CEO rule the code doesn't enforce, and where a terminated agent's reports appear - `instructions-file:put` and `:delete` examples that always failed (`cli/agent.md`) - a curl example that returned `422` (`api/cases.md`) - Google Workspace **Reconnect** instructions, which claimed it reopens the service picker - the `permissionKey` table, which listed 8 of 21 keys - drafting text at the end of `api/agents.md` ## ⚠ Please check these - **Product behaviour that may be a parent bug.** The docs now describe the tag's code, which you may prefer to fix upstream: - The project **Environment** dropdown saves a choice, but runs ignore it (`experimental/environments.md`). - `environments:manage` is granted by roles but no environment route checks it. - `suggest-changes` is documented as agent-only, because only agents have a consent path. Company skill policy decides skill edits. - **Reader-visible mismatches in the parent UI.** The docs follow the code. Upstream copy still mentions a "Built-in agents tab", says Copilot "awaits qualification", and tells people to "Reconnect Google Workspace to change access". ## ⚠ Post-tag leaks removed Nothing to remove from an already-drafted page: post-tag surfaces such as 1Password, Vercel, Supabase deploy, custom gateway onboarding and Artifacts V1 as default never came onto this branch. Authors left out post-tag hunks of the next nightly draft, and the reasons are in the run notes. ## ⚠ Drift None. Zero findings at the tag, from a full parent snapshot. ## ⚠ Verification Failures The tag-accuracy gate reports one leak and nine review entries. None is a real failure: - **Leak:** `reference/cli/service.md`, `paperclipai payload and`. This is a false positive; it's prose from a real message at `cli/src/commands/service.ts:184`. - **Review, 8 new connector pages:** the gate can't confirm new pages. Reviewers confirmed each surface exists at the tag. - **Review, `local_tools`:** an example value from the tag's Runner README. Not provable from code, and kept deliberately: - `sandbox-providers.md` uses `sandbox.yaml`. The tag's README says `install.yaml`, which returned 404 when checked. The upstream fix is post-tag. - The Google Workspace row about older OAuth brokers rests on release notes and a design doc. The broker isn't in this repo. - External claims about provider behaviour (for example Braintrust, Daytona, Unikraft and Google scopes). ## ↻ Renames detected None. The rename helper wasn't run: the 19-commit delta adds no new adapter, skill, or plugin directories that it would check. ## Verification All checks read a checkout pinned to the tag. - **First round:** authors, a release-notes audit, an audit of corrections stranded on `nightly`, an audit of 321 lines the last realign dropped from `main` (about 130 checked directly in code), and six fresh verifiers. - **Second round:** seven new verifiers re-checked every changed area, tracing behaviour rather than matching labels, and fixed about 50 more defects. That volume means more may remain. - **Limits of that second round:** - Each verifier reported what it only string-matched. That includes parts of Artifacts V1, the **Upgrade runner** notice, Copilot run behaviour, and some Plugin SDK contract text. - The second-round fixes themselves weren't reviewed by a third round. - **Gates:** `docs:build`, `docs:test` and `sync:check` pass. - **Nothing was run against a live instance.** All of this comes from reading code. ## Screenshots **196 of 278 screenshots are stale and none were recaptured.** The list is in `SCREENSHOTS_PENDING.md`. Some visibly differ from the text, such as the removed **Run with provider trace** button and the old roster tabs. ## After merge 1. Keep the PR title as is: `tag-docs-release.yml` reads the version from it. 2. Confirm the `docs/v2026.1106.0` tag exists. 3. Run `node scripts/sync/realign-nightly.mjs release/v2026.1106.0 --push`, then audit for dropped lines and duplicated paragraphs, and set `nightly` state back to `branch_mode: nightly`. 4. Check that `docs.paperclip.ing` serves the release: a new page, a new claim, and the changelog's top entry. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]> Co-authored-by: DevRel Gemini <[email protected]> Co-authored-by: Paperclip <[email protected]> Co-authored-by: Dotta <[email protected]> Co-authored-by: ClaudeCoder <[email protected]>
6.3 KiB
paperclip_version, seo_title, seo_description
| paperclip_version | seo_title | seo_description |
|---|---|---|
| v2026.1106.0 | Daytona Sandbox Connector | Let agents manage your Daytona account's sandboxes, files, commands, Git, snapshots, and volumes with an organization API key and per-action controls. |
Daytona
Agents can manage resources in your own Daytona account — creating and stopping sandboxes, reading and writing files, running commands, working with Git, and handling snapshots and volumes.
Daytona appears in the catalog on every instance; no experimental setting is needed. It has not yet been qualified against a live Daytona account.
Note: This is not the Daytona sandbox provider. Paperclip can also run agents inside Daytona sandboxes; that is configured separately, with its own credential, and is covered in Sandbox providers. This connector is a tool: it lets agents work with your Daytona account the way you would from its dashboard or API. The two never share a credential.
Warning: This connection can run commands, read sandbox files and secrets, create resources, and delete data. Choose trusted agents and set action permissions before anyone uses it.
Before you connect
- A Daytona organization API key. Create one at app.daytona.io/dashboard/keys with the read, write, and delete permissions for the resources you want agents to manage.
There is no browser sign-in; the key is the only way in. Be aware that any valid organization key can reach running sandboxes through Daytona's Toolbox, even with no scopes selected. Treat every key as broad access.
Add your Daytona key
- Open Connectors and select Daytona. The card says Add key.
- Read the access line above the main button. It says who the connection belongs to and which agents can use it. Select Change to narrow the agents or to reach the advanced setting below.
- Paste the key into Your Daytona key and select Connect.
Paperclip checks the key with Daytona before saving it. The key stays in Paperclip's vault and is sent to Daytona as a Bearer header; agents never see it.
Optional setting
| Setting | What it does |
|---|---|
| Pin to organization ID | Advanced. Enter a Daytona organization ID, and Paperclip rejects a key or sandbox from any other organization. |
Choose access
The connection exposes Daytona's full published HTTP API: 274 actions, covering the platform API and the per-sandbox Toolbox. Action names come from Daytona, such as daytona_api_list_sandboxes, daytona_api_delete_sandbox, daytona_toolbox_list_files, and daytona_toolbox_execute_command. Sandbox IDs come straight from Daytona. You do not need a Paperclip task or workspace.
Paperclip sorts the actions into three groups:
| Group | Examples |
|---|---|
| Read | Listing sandboxes, reading details, downloading files |
| Write | Creating resources, changing files or Git, starting and stopping, configuration changes |
| Destructive | Deleting anything, running commands or code, resets and restores, reading secrets or credentials, signed access links, account access changes |
Every action starts as Allowed when setup finishes, so set the policy before you hand the connection to an agent:
Danger: Set destructive actions — deleting sandboxes and running commands especially — to Ask first or Off. A command runs inside your Daytona sandbox with whatever that sandbox can reach, and a deletion cannot be undone.
Reading a sandbox is not permission to run a command in it or delete it. Those are separate actions with separate settings. See Set action permissions.
A few account and administrator endpoints need Daytona user sign-in and refuse an API key. When Daytona denies a call, Paperclip does not retry it as someone else.
Try it
Verify with a read:
Use Daytona to list the sandboxes in our account with their state. Do not create, start, stop, or delete anything.
Compare the list with the Daytona dashboard.
Note: Illustrative task, not a recorded test result.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| The key is rejected at setup | The key was revoked or copied incompletely | Create a new key and reconnect |
| A sandbox from another organization is refused | Pin to organization ID is set to a different organization | Check the ID, or clear the pin |
| An account or admin action is refused | Daytona requires user sign-in for that endpoint | Do it in the Daytona dashboard |
| A command or write timed out | Calls are capped at 30 seconds, and the work may still be running in Daytona | Check the sandbox before retrying; Paperclip never retries changes automatically |
| A file upload or download fails on size | Transfers are limited to 8 MiB | Use smaller files or ranges |
| Actions changed after an update | Paperclip refreshed the catalog | Open the connection and review the Permissions tab; new actions need review |
| Needs attention | The key was revoked | Select Reconnect with a valid key |
Limitations: one Daytona organization key per connection. API key only; there is no OAuth sign-in. Interactive streaming sessions (interpreter and terminal) are not offered as actions; use the command and session actions instead. The connector never touches files or runs commands on the Paperclip server itself.
Related guides
- Sandbox providers — running agents inside Daytona, which is separate from this connector.
- How connector access works
- Set action permissions
- Daytona API keys documentation
Sources
- Daytona definition — method, labels, key field, organization pin, and warnings.
- Daytona service — key check, 8 MiB limit, and 30-second deadline.
- Generated action catalog — the 274 actions and the two streaming endpoints.