mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-25 17:45:53 +01:00
6a14cba143eebf94de337c685ecf019216b5ad64
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DottaandPaperclip
|
8f40b4ad4b |
fix(connections): repair and simplify Google Workspace setup (#13289)
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - App connections give agents controlled access to external services.
> - Managed Google Workspace methods depend on profiles enabled for each
Paperclip instance.
> - The catalog used those profiles, but connection creation used static
availability and rejected enabled connections.
> - Switching capabilities also reset personal ownership to company-wide
ownership.
> - This PR uses the same availability rules for catalog and setup, and
preserves supported ownership choices.
> - Paperclip is the default Google authentication method. A small link
opens custom OAuth settings when needed.
> - Local and cloud instances can start the selected Workspace
connection without broadening its audience.
## Linked Issues or Issue Description
**What happened?**
A fresh enrolled instance showed managed Google Workspace apps as
available. The issue was first found with Gmail. Selecting Continue to
sign in returned HTTP 422 with “This app does not have an available
connection method.” Changing from Read & create drafts to Read only also
reset Just me to company-wide ownership.
**Expected behavior**
Start Google authorization for an enabled profile. Keep personal
ownership when the selected method supports it. Reject profiles that the
instance cannot use.
**Steps to reproduce**
1. Start a fresh source test-drive and enroll the instance with
Paperclip Cloud.
2. Open Apps and select Gmail.
3. Select Just me and choose the agents that can use the connection.
4. Continue to setup and select Read only.
5. Go back to inspect ownership, then continue to sign in.
**Paperclip version or commit**
Reproduced on master commit
|
||
|
DottaandPaperclip
|
8c3b8c432a |
Simplify app connections and enable managed Google access (#12728)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The Apps subsystem gives humans and agents governed access to external tools. > - The current connection flow hides Apps behind an experimental gate and repeats setup text. > - Google sharing choices and generic MCP permissions do not use one consistent opening model. > - Self-hosted installs also need a safe default origin for managed OAuth without a manual config file. > - This pull request makes Apps available, simplifies connection setup, and applies one governed permissions model. > - The benefit is a shorter connection flow that works on a clean self-hosted install. ## Linked Issues or Issue Description **What existing behavior does this improve?** This improves the Apps connection setup flow, managed Google connection flow, generic MCP connection flow, navigation, and runtime origin discovery. **Subsystem affected** Cross-cutting. This changes `ui/`, `server/`, `packages/shared/`, connector documentation, and browser tests. **Current behavior** Apps require an experimental switch. Setup pages repeat titles and explanatory copy. Connection names require manual input. Google credential sharing does not always offer both personal and organization access. Generic MCP providers do not start with the same permission choices. Managed OAuth needs a public URL setting even when the request already has a safe HTTPS origin. **Proposed behavior** Apps are available by default. Setup asks only for required permissions and sharing choices. Paperclip creates conflict-free connection names. Google apps and generic MCP providers use the same human and agent access model. Managed OAuth derives a validated same-origin HTTPS URL when no explicit public URL is set. **Reason and benefit** A clean self-hosted install can connect a managed Google app without hidden setup. Humans can share a service account with their organization. The shorter flow reduces duplicated choices and setup errors. **Breaking changes** The Apps experimental switch is removed. Existing connection APIs remain compatible. New connections can receive a numeric suffix when a name already exists. No duplicate or related public issue was found. ## What Changed - Removed the Apps experimental gate and the breadcrumb that leaves the Apps section. - Simplified all connection setup pages and moved optional provider requirements into one small link. - Added consistent human and agent access choices for Google apps, Zapier, and generic MCP connections. - Added organization sharing to Google Workspace credentials while keeping personal access available. - Generated connection names automatically and resolved name conflicts with numeric suffixes. - Derived a validated public HTTPS origin from the request for config-free managed OAuth. - Updated connector contracts, tests, browser coverage, and authoring documentation. ## Verification - `pnpm check:token-gates` - `pnpm -r typecheck` - `pnpm build` - `pnpm exec vitest run server/src/__tests__/tool-access-service.test.ts server/src/__tests__/generic-mcp-connection.test.ts` (273 passed) - Targeted UI/service regression suite (308 passed) - Six targeted Playwright connection journeys on a fresh onboarding instance (6 passed) - Fresh-install browser proof through Tailscale HTTPS: enrolled with Paperclip Cloud, connected managed Google Drive, and completed a real read operation. - [Exact-head CI run](https://github.com/paperclipai/paperclip/actions/runs/33669760711): all 23 matrix jobs passed, including build, typecheck, server, serialized, canary, and all browser shards. - Greptile 5/5 on `0ae2a859f269984ee950d0af231a5b09a06f3dfd`, with no unresolved review threads. ## Risks Apps are now visible to all operators. The removed experimental flag no longer hides unfinished app definitions. Managed Google availability still depends on the Cloud profile rollout and active instance enrollment. Automatic conflict handling changes only the display name of a newly conflicting connection. > I checked [`ROADMAP.md`](ROADMAP.md). MCP Tool Gateway and Apps are shipped. Connected Apps is planned, and this change improves the existing shipped connection flow. ## Model Used OpenAI Codex, GPT-5, with reasoning, browser control, tool use, and code execution. ## 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 - [x] All Paperclip CI gates are green - [x] 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> |
||
|
DottaandPaperclip
|
c7ebc089cb |
fix(apps): complete managed Google Workspace rollout (#12619)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Apps system gives agents governed access to external services > - The managed Google Workspace connector uses separate profiles for each app and access level > - Several app definitions and callback paths did not enforce the same profile contract > - The default method could also select a customer OAuth setup when a managed read profile was available > - This pull request aligns the profile contracts, setup guidance, default selection, and activity attribution > - The benefit is a consistent managed connection flow for every Google Workspace app ## Linked Issues or Issue Description N/A — no public GitHub issue exists for this follow-up. Related merged work: [#12600](https://github.com/paperclipai/paperclip/pull/12600) and [#12609](https://github.com/paperclipai/paperclip/pull/12609). This change follows the merged Paperclip Cloud managed OAuth broker work. It does not add a new broker or provider client. **What happened?** The Google Workspace connection definitions could drift from the shared connector profile registry. The callback activity always named Gmail. Google Sheets did not show the Developer Preview requirement. The setup flow could select a customer-owned write method when Cloud advertised only a managed read profile. The tool-access service had no non-Gmail managed callback test. **Expected behavior** Each managed Google Workspace profile must use its exact app slug, MCP URL, scopes, ownership, risk tier, and write-tool policy. Callback activity must name the correct app and profile. Every Google Workspace card must show the same Developer Preview prerequisite. An available managed method must be the default within the selected capability. The customer-owned method must remain available as a fallback. **Steps to reproduce** 1. Advertise only the `gmail.read` managed profile. 2. Open the Gmail connection setup. 3. Observe that the customer-owned draft method becomes the default. 4. Complete a managed Google Drive callback. 5. Observe that the activity row names Gmail instead of Google Drive. 6. Open the Google Sheets setup. 7. Observe that it does not show the Google Developer Preview prerequisite. **Paperclip version or commit** Current `master` at the start of this follow-up. **Deployment mode** Local development. The same connector definitions apply to Cloud-hosted and self-hosted instances. **Installation method** Built from source with pnpm. **Agent adapter(s) involved** Not adapter-specific. This change affects the core Apps and tool-access paths. ## What Changed - Added one table-driven invariant for all 16 Google Workspace profiles. - Verified each profile against its app slug, MCP URL, exact scopes, capability, ownership, grant kind, risk tier, and write-tool allowlist. - Kept the Google Chat write profile least-privilege because its only enabled write tool is `send_message`. - Added the Google Developer Preview prerequisite to Google Sheets. - Preferred an available Paperclip-managed method before a customer-owned method. - Preserved explicit capability selection and the customer OAuth fallback. - Switched managed-profile availability from the anonymous global capability document to the enrolled instance's signed status response, so internal-pilot profiles cannot be enabled locally without an authorized instance binding. - Replaced the Gmail callback activity constant with the validated app slug and connector profile. - Added connector and route coverage for signed per-instance capabilities, including inactive and malformed responses. - Added a Google Drive callback test that covers the signed profile request, personal vault refs, encrypted secret rows, catalog filtering, and non-sensitive activity details. ## Verification - `pnpm -r typecheck` — passed across all workspaces before the signed-capability follow-up; final targeted shared and server typechecks also passed after it. - `pnpm exec vitest run server/src/services/paperclip-cloud-connector.test.ts` — passed, 9 tests. - `pnpm exec vitest run packages/shared/src/app-definitions.test.ts` — passed, 19 tests. - `pnpm exec vitest run server/src/__tests__/tool-access-service.test.ts` — passed, 205 tests. - `pnpm test:run` — incomplete after the general server group reported five failures in `server/src/__tests__/workspace-runtime.test.ts`. The failures are outside the changed files. The run was stopped before the remaining serialized suites because the shared worktree was needed for a follow-up edit. - `pnpm build` — passed on the final tree. - `git diff --check` — passed on the final tree. The five full-suite failures were: - `records teardown and cleanup operations when a recorder is provided` - `does not accept an occupied allocated port when listener ownership is unavailable` - `backfills a pre-existing HTTP-only managed worktree runtime to verified HTTPS in place` - `re-adopts a live service whose shell command differs from the surviving process argv` - `reuses a registered legacy worktree that already has the branch checked out` ## Risks - The default setup method changes when at least one Paperclip-managed method is available. Explicit read, write, or draft choices still stay within the selected capability group. - Managed method availability now depends on Paperclip Cloud's signed enrolled-instance status. A Cloud outage or an inactive enrollment hides managed methods while leaving customer-owned OAuth available. - The callback activity schema gains a non-sensitive `profile` value. It does not include tokens, account identifiers, emails, tenant identifiers, or provider error text. - The profile invariant is strict. A future Google scope or tool change must update the shared registry and the matching app definition together. - There are no database migrations and no public API changes. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5.6, with reasoning, repository tools, code execution, and test execution. The effective context window was managed by the Codex task runtime. ## 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 - [ ] 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 - [x] All Paperclip CI gates are green - [x] 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> |
||
|
DottaandPaperclip
|
a7e6b818e9 |
feat(apps): add Paperclip Cloud managed OAuth connector (#12600)
## Thinking Path > - Paperclip lets operators give governed tools to AI agents. > - Connected Apps already support provider OAuth and personal connection grants. > - Some providers require one stable callback and do not support dynamic client registration. > - Self-hosted Paperclip instances can run at private or changeable origins. > - Paperclip Cloud can provide the stable callback while each instance keeps its durable provider credentials. > - This pull request adds the instance side of that managed OAuth protocol and keeps customer-created clients available. > - The benefit is a safe path to one-click Workspace connections for hosted and enrolled self-hosted instances. ## Linked Issues or Issue Description **Subsystem affected** Cross-cutting. This change updates the server, Apps UI, shared app definitions, and connection documentation. **Problem or motivation** Some OAuth providers require a pre-registered callback and provider-owned client. An arbitrary self-hosted Paperclip origin cannot use that client callback directly. Paperclip ID must also stay limited to product identity instead of resource authorization. **Proposed solution** Use the existing Paperclip Cloud application as the fixed callback broker. Enroll each instance to an exact origin and separate Ed25519 and X25519 keys. Bind every request and sealed envelope to the instance, environment, user, company, provider, profile, and exact scope set. Store durable provider credentials only in the originating instance vault. **Alternatives considered** Customer-created OAuth clients remain available as the independent fallback. A generic redirect relay was rejected because it would allow caller-selected destinations and scopes. Paperclip ID was rejected as the broker because it is the identity boundary. A new service was rejected because the existing Cloud application already owns customer login and the public callback origin. **Roadmap alignment** This work extends the shipped MCP Tool Gateway and Apps milestone. It also supports the Connected Apps and Cloud deployments roadmap items. Companion Cloud implementation: https://github.com/paperclipai/paperclip-cloud/pull/312 The duplicate search found no related open Paperclip PR or issue. ## What Changed - Add a `paperclip_cloud_connector` client with signed requests, exact profile and scope bindings, and X25519-sealed credential handling. - Add explicit self-hosted enrollment with owner-only instance key storage and exact HTTPS origins. - Route managed Google Workspace setup through Paperclip Cloud and preserve customer-created OAuth clients. - Keep broker claims retryable until the local vault transaction commits. - Keep managed Google per-profile removal local-only to avoid client-wide provider revocation. - Add setup status to the Connections page and retain the Paperclip ID names as compatibility aliases. - Document the trust boundaries, enrollment, callback, refresh, removal, and rollout flows. ## Verification - `pnpm -r typecheck` - `pnpm --filter @paperclipai/shared exec vitest run src/app-definitions.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/services/paperclip-cloud-connector.test.ts src/services/paperclip-cloud-connector-enrollment.test.ts` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts -t 'brokered Gmail OAuth|brokered OAuth state'` - `pnpm --filter @paperclipai/ui exec vitest run src/pages/apps/Connections.test.tsx` - `pnpm check:token-gates` - `pnpm build` - The full stable test runner also reproduced existing macOS workspace, skill-discovery, and listener fixture failures outside the changed paths. GitHub Linux CI is the authoritative full-suite result. ## Risks - The managed flow depends on https://github.com/paperclipai/paperclip-cloud/pull/312. Real provider profiles stay disabled until Cloud deploys that protocol and the provider approves the managed client. - A Cloud outage blocks new authorization and refresh. Existing access tokens continue to work until expiry. - Managed Google profile removal only deletes the local grant. This avoids invalidating the user's other profiles that share the managed Google client. - Legacy `paperclip_id_connector` records require a reconnect after their current access tokens expire. Old Paperclip ID keys and refresh tokens are not sent to Paperclip Cloud. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI GPT-5.6 (Codex). Agentic coding, tool use, code execution, and subagents were enabled. The context-window size is not exposed in this session. ## 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 - [x] All Paperclip CI gates are green - [x] 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> |
||
|
Dotta
|
d387cc0ff0 |
feat(connections): add managed external MCP connectors (#12346)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Connection intents need secure provider implementations to complete setup. > - Some providers use managed OAuth or external credential brokers. > - Those tokens must stay out of durable Paperclip state and fail closed when refresh fails. > - This pull request adds managed connector backends and the required storage contract. > - The benefit is safer provider setup with governed credential lifecycles. ## Linked Issues or Issue Description Refs #11965 This is stack 8 of 11. It depends on stack 7 and replaces another reviewable part of #11965. ## What Changed - Add managed Google Workspace and external connector backends. - Add Vercel Connect support without storing provider bearer tokens. - Add replay-safe migration 0232 and its generated snapshot. - Fail closed and clear stale token bindings when organization OAuth refresh needs reauthorization. ## Verification - `pnpm --filter @paperclipai/server typecheck` - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/tool-access-service.test.ts` - Result: 194 tests passed. - `pnpm --filter @paperclipai/db check:migrations` - `pnpm build` - `pnpm exec vitest run --project @paperclipai/server server/src/services/remote-url-credentials.test.ts` (5 passed, including URL userinfo vault extraction) ## Risks - Broker metadata errors can block provider setup. - OAuth refresh failure disables the shared organization connection until reauthorization. - Migration 0232 is generated, ordered after 0231, and safe to replay. > I checked `ROADMAP.md`. This stack continues the existing app connection work from #11965 and does not duplicate another planned item. ## Model Used OpenAI Codex, GPT-5. The runtime model ID and context window were not exposed. The model used reasoning, tool use, and code execution. ## 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 linked the public source pull request with `Refs #` - [x] I have not referenced internal or instance-local Paperclip issues or links - [x] My branch name describes the change 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 - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge |