Skip to content

Your own Google OAuth client

Some QuickAgents read your Gmail, Drive or Calendar through an MCP server that signs you in on Google's own consent screen. Google lets no app register itself for that, so until Agentry has a Google app of its own, the sign-in uses an OAuth client you make in Google Cloud. You make it once. Every QuickAgent you connect to Google from the same computer uses it, and each QuickAgent version still asks for your consent the first time it runs.

You need it on this computer with Agentry Desktop 0.6.70 or newer, and with the CLI since v0.6.70. A run in Agentry needs a client of its own kind, kept in Agentry (below).

Make the client

These are the steps the desktop shows on Connect tools when Google asks for a client of your own. The CLI prints a shorter version of them. For a run in Agentry, step 8 differs (below).

  1. In the Google Cloud console (console.cloud.google.com), create a project or pick one of yours.
  2. APIs & Services → Library: enable the API of each Google product the QuickAgent reaches. For Gmail that is the Gmail API. A QuickAgent that uses one of Google's own remote MCP servers needs that server's MCP API as well, for example the Gmail MCP API (gmailmcp.googleapis.com) beside the Gmail API.
  3. Google's remote MCP servers only: they are in Google's Workspace Developer Preview. Enrol the project at developers.google.com/workspace/preview. Google asks for a Google Workspace account, and enrolment can take a couple of days. Until the project is enrolled, Google refuses every call with "The caller does not have permission". A QuickAgent that uses the workspace-mcp server instead reaches Gmail through the Gmail API alone and needs no enrolment.
  4. Google Auth Platform → Branding: give the app a name and your email address.
  5. Audience: choose Internal if your account is in a Google Workspace organization. Otherwise choose External, then Publish app so it is In production. A client left in Testing gets sign-ins that stop working after 7 days.
  6. If the app stays in Testing: Audience → Test users → Add users, and add the Google account you will sign in with. Google refuses the sign-in of any account a Testing app does not list.
  7. Data Access → Add or remove scopes: add the scopes the QuickAgent asks for. The run setup and the CLI show them, for example https://www.googleapis.com/auth/gmail.readonly.
  8. Clients → Create client → Application type: Desktop app. Copy its client ID and client secret.

When you sign in with a client of your own, Google may show an "unverified app" screen. The app is yours. Google says so because it has not reviewed it.

Use it

In the desktop. Open the QuickAgent's run setup and go to Connect tools. Each MCP server that signs you in has a card with Connect. The first time a vendor asks for a client of your own, the card shows the steps above, then fields for the client ID and secret. Keep it and connect keeps the client and opens Google's consent screen in your browser. Approve it, and the card says the server is connected. The next run of that version asks nothing.

If your browser is on another computer, the page it ends on (an address that starts with http://127.0.0.1) does not load. Paste that page's whole address into the field under the consent address on the card.

In the CLI. agentry run, or agentry connect ns/name@version ahead of a run, asks for the client the same way on a terminal. You can also keep it first:

agentry connections client set https://accounts.google.com --client-id <your client ID>

The secret is read without echo.

Where it is kept

  • The client. Once per vendor on each computer, its secret in the OS keychain (the macOS Keychain, Windows Credential Manager, or the Secret Service on Linux), or in a file only you can read where no keychain answers. It is never shown again, never logged and never sent into a run.
  • Each connection. One per QuickAgent version and server, kept the same way. A run is given a short-lived access token and nothing else: never the refresh token, never the client secret.
  • The desktop and the CLI keep both in the same place, so either one lists and removes what the other made: Settings → Connections in the desktop, agentry connections list and agentry connections client list in the CLI.

Disconnect and Forget

Disconnect in Settings → Connections, or on the run setup's card, removes a connection from the computer and asks Google to revoke it.

Google revokes everything you granted to a client, not one connection. So when other connections were made with the same client, Disconnect ends them too, and each asks for your consent again at its next run. The desktop's Disconnect dialog names those connections before you confirm. In the desktop, connecting a server again with the same client replaces the connection without revoking anything. The CLI's agentry connect --again still revokes the old connection after making the new one, which at Google ends the new one too: connect again from the desktop instead.

Forget under Your OAuth clients removes the client from this computer. It stays in Google Cloud, where you made it. The connections made with it stop working and ask again when they next run.

For runs in Agentry

A run in Agentry signs in through Agentry's own site, so its client is a Web application client rather than a Desktop app one, and Agentry keeps it in your vault. These are the steps the site's run setup shows on Connect tools when Google asks for a client of your own:

  1. In the Google Cloud console, create a project or pick one of yours.
  2. APIs & Services → Library: enable the API of each Google product the QuickAgent reaches, such as the Gmail API. For one of Google's own remote MCP servers, enable its MCP API as well, such as the Gmail MCP API.
  3. Google's remote MCP servers only: enrol the project in Google's Workspace Developer Preview, as in step 3 above.
  4. Google Auth Platform → Branding: give the app a name and your email address.
  5. Audience: Internal in a Google Workspace organization, otherwise External and Publish app. A client left in Testing gets sign-ins that stop working after 7 days, and Google refuses any account not listed under Test users.
  6. Data Access → Add or remove scopes: add the scopes the run setup shows for the server.
  7. Clients → Create client → Application type: Web application. Under Authorized redirect URIs, add the address the run setup names. On secureagentry.net it is https://secureagentry.net/api/v1/x/vault/me/connections/callback. Copy the client ID and client secret into the fields the step shows.

Keep it and connect keeps the client in your vault and opens Google's consent screen. Approve it, and you come back to the run setup, which says the server is connected. The next run of that version asks nothing.

The client is kept once for Google in your account, and every connection you make to Google in Agentry uses it. Its secret is never shown again and never reaches a run: a run is given a short-lived access token and nothing else. Settings › Encrypted storage lists the client under Your OAuth clients, beside your connections, and keeps one there too. A connection made in Agentry and one made on your computer are separate, and each asks for your consent once.

Disconnect there removes a connection from Agentry and asks Google to revoke it, which, as on the desktop, ends every connection made with the same client: the dialog names them. Forget removes the client from your vault once no connection uses it.