Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/cloudflare/cloudflare-os/llms.txt

Use this file to discover all available pages before exploring further.

The Google Gatekeeper connects Cloudflare OS to Google Workspace via OAuth 2.0, giving agents and Gadgets the ability to read and write Google Docs, work with spreadsheet data in Sheets, manage calendar events, access Gmail mailboxes, and query BigQuery datasets. It also powers “Continue with Google” sign-in using minimal identity scopes, entirely separate from the broader data-access scopes requested when you connect a specific Google resource.
The Google Gatekeeper uses incremental scopes — sign-in requests only openid, userinfo.email, and userinfo.profile. Full data-access scopes (e.g., documents, gmail.modify) are only requested when a user connects a specific resource type. This means sign-in is always fast and low-friction, while data scopes remain narrow and purposeful.

Capabilities

The scopes requested by the Google Gatekeeper depend on what the user is connecting:
Resource typeScopes requestedWhat agents can do
Sign-inopenid userinfo.email userinfo.profileRead verified email for identity only
Google Docsdocuments drive.metadata.readonly + identityRead and write document content
Google Sheetsspreadsheets.readonly drive.metadata.readonly + identityRead metadata and cell values
Google Calendarcalendar.calendarlist.readonly calendar.events + identityList calendars, read/write events, check availability
Gmailgmail.modify + identityRead threads, reply, forward, send, manage labels
BigQuerybigquery + identityRun read-only SQL queries and explore datasets
BigQuery uses the bigquery scope rather than bigquery.readonly because dry-run jobs require jobs.insert. The gatekeeper enforces read-only SQL and resource scope checks in the session layer before any query is executed.
The Google Drive API (drive.metadata.readonly) is used only to search and display document and spreadsheet metadata in the resource pickers. Document reads and edits continue to go through the Google Docs API; spreadsheet reads go through the Google Sheets API.

Setting Up Google OAuth Credentials

1

Create a Google Cloud project

  1. Go to the Google Cloud Console.
  2. Click the project dropdown at the top of the page and choose New Project.
  3. Enter a project name (e.g., “My Company OS”) and click Create.
  4. Select the new project from the dropdown once it is ready.
2

Enable the required APIs

In the left sidebar, go to APIs & Services → Library and enable each API you plan to use:
  • Gmail API (for Gmail mailbox access)
  • Google Docs API (for Google Docs read/write)
  • Google Drive API (for document metadata in resource pickers)
  • Google Sheets API (for spreadsheet data)
  • Google Calendar API (for calendar events and availability)
  • BigQuery API (for dataset queries)
You do not need to enable all APIs at once — only enable what you plan to offer.
3

Configure the OAuth consent screen

In the left sidebar, go to APIs & Services → OAuth consent screen.
  1. Select External as the user type (or Internal for a Google Workspace organization).
  2. Click Create and fill in an app name and any required fields.
  3. On the Scopes page, you can skip adding scopes manually — the consent screen is controlled by the OAuth request itself, not the console configuration.
  4. On the Test users page, add the email addresses of any users who should be able to sign in while the app is in Testing mode.
While the app is in Testing mode, only addresses listed as Test Users can complete the OAuth flow. Add every developer or tester who needs access during setup.
4

Create OAuth credentials

  1. In the left sidebar, go to APIs & Services → Credentials.
  2. Click Create Credentials → OAuth client ID.
  3. For Application type, choose Web application.
  4. Under Authorized redirect URIs, add:
    • http://localhost:8787/gatekeeper/google/oauth for local development
    • ${PUBLIC_BASE_URL}/gatekeeper/google/oauth for production
  5. Click Create and copy the Client ID and Client secret from the popup.
5

Configure credentials

Create a .env file in the gatekeeper package directory:
packages/gatekeeper-google/.env
CLIENT_ID=your-client-id-here.apps.googleusercontent.com
CLIENT_SECRET=your-client-secret-here
The .env file is gitignored and should never be committed to source control.
6

Enable Google sign-in (optional)

To show “Continue with Google” on the login page, add google to the AUTH_GATEKEEPERS allowlist:
.dev.vars
AUTH_GATEKEEPERS=cloudflare,google,github
Sign-in only needs the identity scopes, which are always available. No additional Google configuration is required for sign-in specifically, though the signing-in user must be listed as a Test User while the app is in Testing mode.

Observer Tracking for Google Resources

Cloudflare OS tracks what external data a Gadget reads so that it can correctly verify collaborator access when a Gadget is shared. Google resources follow different strategies depending on the resource type:
ResourceSharing behavior
Google DocsCollaborator must connect their own Google account and verify access to the specific document
Google SheetsCollaborator must connect their own Google account and verify access to the specific spreadsheet
Google CalendarCollaborator must verify access to the specific calendar
GmailPrivate-only — observer access is always denied. Gmail mailboxes are never shared through a Gadget
BigQueryCollaborator must verify access to the specific dataset
When a collaborator opens a Gadget that uses a Google Doc they also have access to, they are prompted to connect their own Google account. If they do not have access, the Gadget cannot open for them.

Example Agent Prompts

Here are some prompts you can use once Google resources are connected:
"Fix the typos in this Google Doc." (attach a Google Doc URL)
"Summarize the Q3 results from this spreadsheet and generate a slide deck."
"Find a 30-minute meeting slot where all three of these calendars are free next week."
"Search my inbox for emails about the Acme contract from the last 30 days."
"Run a BigQuery query to count the number of signups by country in the last 7 days."

Troubleshooting

The redirect URI in your OAuth credentials does not match what the application is sending. Verify that http://localhost:8787/gatekeeper/google/oauth (no trailing slash, http not https for localhost) is listed under Authorized redirect URIs in the Google Cloud Console.
Two common causes: (1) the signing-in user is not listed as a Test User while the app is in Testing mode — add their email in the OAuth consent screen settings; (2) the user clicked Cancel on Google’s consent screen — ask them to try again and click Allow.
Your CLIENT_ID or CLIENT_SECRET is incorrect. Double-check the values in your .env file match exactly what is shown in the Google Cloud Console.

Build docs developers (and LLMs) love