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]>
9.8 KiB
paperclip_version, seo_title, seo_description
| paperclip_version | seo_title | seo_description |
|---|---|---|
| v2026.1106.0 | Set Up the GitHub Connector | Step-by-step setup for both GitHub routes — repository tools with a managed identity or a fine-grained token, and the GitHub App for chat from issues. |
Set up the GitHub connector
Two separate procedures, because GitHub does two unrelated jobs. Pick the one you need:
- Set up GitHub as an agent tool — agents read and act on repositories.
- Set up chat from GitHub — people work with an agent from issue and pull-request comments.
Want agents to run on your GitHub Copilot plan instead? That's a separate AI connection under Connect Copilot on the same GitHub row. See GitHub Copilot.
For what each route governs, and the shell Git and gh exception, see GitHub. Read the exception before granting an agent a dedicated identity.
Set up GitHub as an agent tool
1. Decide the identity first
Deciding which identity and which repositories is the part worth slowing down for, because GitHub-side scope is the real limit on what an agent can do.
| Identity | Choose it when |
|---|---|
| My GitHub account | You want an agent acting as you, on your work, while you are the responsible person |
| A dedicated account for an agent | The agent should appear as itself in commits, comments, and pull requests. Requires the connection-manager permission |
For anything that pushes code, a dedicated account is the better answer. Its actions are attributable, and revoking it does not disturb a person's own access.
2. Start the connection and pick a credential path
- Select Connectors in the sidebar.
- Find GitHub and select Connect.
- Read the access line above the main button. It says who the connection signs in as and which agents can use it. To change either, select Change: answer Connect GitHub as with the identity from step 1, and choose Any agent or Only agents I choose. For a dedicated identity the agent question is already settled — Paperclip asks Which agent owns this GitHub account? instead.
- Check the credential path. When the managed path is offered, setup starts on it; the token path sits under Change as the alternative:
| Path | What it is | Offered when |
|---|---|---|
| Connect GitHub | Paperclip's managed GitHub App authorization | Only when the instance is enrolled with Paperclip Cloud and Cloud advertises the GitHub connector profile |
| Personal access token (advanced) | A fine-grained token you create and control | Always |
The two branches do not share steps from here. Follow 3a or 3b, not both.
3a. Managed path — authorize and choose repositories in GitHub
- Select Continue to GitHub and authorize.
- On GitHub's installation screen, select the specific repositories the agent should reach. Avoid All current and future repositories unless that is genuinely the intent — Paperclip flags such an installation in the repository row, because it widens on its own as the organization grows.
Back in Paperclip, the identity card shows Accessible GitHub repositories. To change the list later use Add More Repos on GitHub or Configure access on GitHub, then Refresh access so Paperclip re-reads the installation.
This branch is the only one that produces a durable identity for shell Git and gh.
3b. Token path — create the token, then paste it
There is no authorization redirect and no GitHub installation screen on this branch. Repository scope lives on the token, so you set it while creating the token rather than afterwards in Paperclip.
- In GitHub, go to Settings → Developer settings → Personal access tokens → Fine-grained tokens, and select Generate new token. Direct link: github.com/settings/personal-access-tokens/new.
- Set the Resource owner to the account or organization that owns the repositories. If it is an organization, the token may need an organization owner's approval before it works — expect that delay rather than assuming the token is broken.
- Under Repository access, choose Only select repositories and pick exactly the repositories agents should use.
- Set an Expiration. A token that expires is a feature here; note the date, because the connection will stop working on it.
- Grant repository permissions to match what you want agents to do, and no more. Read-only Contents, Metadata, Issues, and Pull requests is a sensible starting point; add write permissions deliberately, one at a time.
- Generate the token and copy it. GitHub shows it once. It begins
github_pat_. - Back in Paperclip, paste it into the Your GitHub key field and finish. The connection is complete at that point — there is nothing further to authorize.
Note: Because the permissions are the ones you ticked on the token, this path is the easier of the two to audit. What it does not give you is a durable shell identity: for that, use the managed path.
To change repository scope later, edit the token in GitHub or issue a new one and reconnect. Refresh access re-reads an installation and does not apply here.
4. Set the actions
On the Permissions tab, work down the list: reads Allowed; writes and destructive actions Ask first or Off until you have watched the agent work.
Paperclip shows the shell warning when you change a permission on a dedicated GitHub identity. Read it as written: shell Git and gh use that account and are not bounded by these switches.
5. Put the real guardrails on GitHub
Because the shell is not gated by action permissions, the controls that matter for an agent with push access live on GitHub:
- For the managed App, grant selected repositories. For a PAT, restrict repository selection and token permissions in GitHub.
- Protect the default branch: require a pull request, and require a review from someone other than the agent.
- Require status checks to pass before merge.
Paperclip's execution policy can also require a review stage on the Paperclip issue, but a Paperclip review stage and a GitHub branch protection rule are separate controls. Set both if merges matter.
6. Verify with a read
As the agent you intend to use, ask it to read a known file in an intended repository. Compare the content and inspect the task's connector call. Check managed App installation settings or, for a PAT, its repository selection and permissions separately. A successful read verifies that operation, not the entire access boundary.
Do not verify with a push, a pull request, or a merge.
Set up chat or a PR review bot from GitHub
Experimental: Enable GitHub review bots in the instance's experimental settings before starting this path. It is separate from Chat connectors.
The review bot has its own entry on the Connectors page, GitHub Code Review Bot, separate from the GitHub entry for repository tools. Selecting it goes straight to choosing the agent.
Follow Set up a GitHub review bot for the complete setup, including an optional Storybook reviewer. It covers choosing the agent, creating and installing the App from GitHub, repository access, personal account linking, and a real PR test. A new bot starts in mentions-only mode; leave Run automatically off if you want a bot that only answers mentions.
Read Understanding GitHub PR review bots first if you are deciding whether reviews should run automatically or block merges. Installing the App does neither by itself.
Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
| The managed tool option is missing | No Paperclip Cloud enrollment, or the GitHub connector profile is not advertised | Use Personal access token (advanced) |
| A fine-grained token is rejected, or reaches nothing | It targets an organization that has not approved it, or its repository selection is empty | Check for a pending approval under the organization's personal-access-token settings, and confirm the token's selected repositories |
| A token connection stops working on a particular date | The token expired | Issue a new token with the same scope and reconnect |
| No webhook URL is shown on the chat setup | The instance has no public base URL configured | Ask an administrator to configure it |
| GitHub Code Review Bot is missing from Connectors | GitHub review bots is off for the instance | Ask an administrator to enable it |
| Fewer repositories than expected | The installation does not include them | Fix it on GitHub, then Refresh access |
| "You don't have permission to reconnect this identity." | The identity belongs to someone else, or to another agent | Ask its owner, or use your own |
Tool calls work but git push is rejected |
Account permissions or branch protection on GitHub | Check both on GitHub |
| Webhook deliveries fail in GitHub's App log | The webhook URL or secret does not match | Regenerate the secret in Paperclip and update the App |
| A comment creates no task | The App is not installed on that repository, or the two comment events are not subscribed | Install it there and check the events |
More in Verify a connector and fix a broken one.