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]>
8.5 KiB
paperclip_version, seo_title, seo_description
| paperclip_version | seo_title | seo_description |
|---|---|---|
| v2026.1106.0 | Set Up the Gmail Connector | Get Google Developer Preview access, connect Gmail with the read, draft, or archive capability group, and restrict which agents can search your mail. |
Set up the Gmail connector
Warning: Google verification pending. Paperclip has not yet completed Google app verification. You may see an unverified-app warning during authorization. If Google offers an Advanced option to continue to Paperclip, you can choose to proceed after reviewing the requested access. This option is not available for every account; Workspace administrator restrictions and other Google access requirements still apply. Contact [email protected] if you cannot connect.
Note: This connector is no longer listed on the Connectors page for new setup; it appears there only when you have a saved connection to it, which keeps running unchanged. For a new Google account, use Google Workspace. An agent that needs this service can still ask you for it with a connection card on its task.
Two phases: get Google to register you for Developer Preview, then connect. The first phase is the slow one and happens entirely at Google.
For what the connector can and cannot do once it is connected, see Gmail.
1. Get Developer Preview access
Google's Workspace MCP servers are in Developer Preview. Google registers both the Workspace email that will sign in and the Google Cloud project that owns the OAuth client. Registration covers only the emails and projects you name.
- Apply at Google Workspace Developer Preview with the Workspace email that will authorize Paperclip and the Google Cloud project that owns the OAuth client.
- Wait for the Google Group notification, then Google's final project-registration email. Google's guidance is usually a couple of days.
- Add every additional tester email and every additional Cloud project through Google's member request forms before connecting them. An unregistered account fails at authorization, not at connect time.
If you plan to use Connect with Paperclip rather than your own OAuth client, the Workspace email still has to be registered — the Cloud project on that path is Paperclip's.
2. If you are bringing your own OAuth client
Skip this section if your instance is enrolled with Paperclip Cloud and Connect with Paperclip is offered.
In the Google Cloud console:
- Enable the Gmail API and the Gmail MCP API on the project.
- Create an OAuth client of type Web application and add Paperclip's callback as an authorized redirect URI. Paperclip shows the exact URI during setup — copy it from there; it is the
/api/tools/oauth/callbackroute on your instance's origin, and it must match exactly. - Keep the client ID and client secret to hand.
Set up your own Google OAuth app covers this in full, including the redirect-URI failure mode, and is the same procedure for every other Google connector. Google's own walkthrough is Configure MCP servers.
3. Decide the capability group before you start
This is the decision that matters, and it is fixed for the life of the connection.
| Group | Scopes requested | Use it when |
|---|---|---|
| Read only | gmail.readonly |
Agents need to find and read mail. Nothing is written to the mailbox. |
| Read & create drafts | gmail.readonly, gmail.compose |
An agent should leave a draft for a person to review and send. |
| Read & archive | gmail.readonly, gmail.modify |
An agent should clear processed threads out of the inbox. Archiving removes only the Inbox label; nothing is deleted. |
No group makes sending reachable. Setup starts on Read & create drafts. If agents only need to read, switch to Read only while you connect (step 4) — it is the safer choice unless you have a concrete reason for drafts. Read & archive is opt-in; you only get it by choosing it. If you use your own OAuth app for it, add gmail.modify alongside gmail.readonly under Data Access — see Set up your own Google OAuth app.
Even though gmail.modify allows more at Google's end, an archive connection can only remove the Inbox label. Trashing, marking spam, and other label changes stay unavailable — see Gmail.
To change groups later, create a second connection with the group you want and remove the first. The group is part of the connection, so Reconnect re-runs sign-in for the same group rather than changing it.
4. Connect
Setup is one screen. Paperclip fills in a default for who the connection belongs to and which agents may use it, and you change anything that does not fit before you sign in.
- Select Connectors in the sidebar.
- Find Gmail and select Add account. The row is there only when you already have a saved Gmail connection. Without one, start from the connection card an agent posts on its task.
- Read the access line above the main button. It says who the connection signs in as and which agents can use it. For a mailbox, the default is rarely what you want, so select Change:
- Under Which humans can use this credential?, Just me is the usual answer for a mailbox — agents use the credential only on runs where you are the responsible person. Any human in the organization makes one mailbox available on runs started by anyone in its human audience, which you set on the connection's identity card as either Any human in the company or Humans I pick with a named list. Narrow that audience for a mailbox: leaving it open means any colleague's run can read the inbox. It requires the connection-manager permission and suits a genuinely shared inbox, not a person's mail.
- Under Which agents can use this connection, choose Just agents I pick and name them. A mailbox is not something to hand to every agent by default.
- Under What should Paperclip be able to do?, pick the capability group from step 3.
- Choose the setup path:
- Connect with Paperclip — Paperclip's managed Google client. Offered only when the instance is enrolled with Paperclip Cloud and Cloud advertises the Gmail profile. Setup uses it by default when it is offered.
- Use your own Google OAuth app — select it to supply the client ID and secret from step 2. Use Paperclip instead switches back.
- Complete Google's consent screen with the registered Workspace account.
5. Set the actions
Open the Permissions tab.
- Leave the reads Allowed.
- If you connected the archive group,
unlabel_threadalready starts on Ask first, so each archive waits for a person's approval. Keep it there while you learn how the agent decides a thread is done. - If you connected the draft group, consider setting
create_draftto Ask first. Drafts land in a real mailbox, and the connector's own guidance recommends approval for them. This is advice, not something Paperclip enforces — unlike sending, which is blocked outright whatever you set.
6. Verify with a read
As the agent you intend to use, run one read whose answer you already know — a thread search against a sender you can see in Gmail — and confirm the result matches. This confirms the credential, the account, and the agent's permission together.
Then check the connection's activity shows the Gmail calls. Matching output alone does not establish that the mailbox was actually read.
Do not verify by creating a draft.
If authorization fails
| Symptom | Cause |
|---|---|
| Google refuses before the consent screen | The signing-in Workspace account or the Cloud project is not registered for Developer Preview. |
| Connect with Paperclip is not offered | The instance is not enrolled with Paperclip Cloud, or Cloud is not advertising the Gmail profile. |
| Consent completes but the connection shows Setup incomplete | The final step was not finished. Select Finish setup. |
| Redirect URI mismatch | The callback URI registered on your Google OAuth client does not match the one Paperclip displays. |
More in Verify a connector and fix a broken one.