## 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>
c7ebc089cb