The Google Workspace extension for Gemini CLI, and what it grants

Workspace data becomes reachable from a natural language prompt

The Google Workspace extension for Gemini CLI exists to close the gap between a terminal session and the apps most people use at work. The description of the extension is plain: it brings Workspace apps to your command line so you can manage documents, spreadsheets, presentations, emails, chat and calendar events without leaving the terminal.

That is a genuine capability and also a genuine risk, and the project itself makes the second point loudly. The extension is an MCP server, and the documentation states that it grants the agent the ability to read, modify and delete your Google Account data, as well as other data shared with you. Everything else in this review follows from that sentence.

The codebase is TypeScript and the repository layout reflects a monorepo shape: a workspace-server workspace listed in package.json with a compiled entry point at workspace-server/dist/index.js, plus top level directories for commands, skills, cloud_function, scripts and docs. The root also holds gemini-extension.json, the manifest that describes the extension to the CLI, and GEMINI.md.

There is one practical prerequisite before any of this works: you need to be logged into your Google account.

Slash commands wrap the Workspace APIs

The extension exposes two layers of interface. The first is natural language. The documentation gives examples of prompts such as creating a new Google Doc with a title and content, asking what is on the calendar for today, and finding a file named my-file.txt in Google Drive.

The second layer is explicit slash commands, which are the more predictable entry point. The documented set includes /calendar:get-schedule [date], which shows your schedule for today or for a specified date, and /drive:search <query>, which searches Google Drive for files matching the given query. The documentation says the extension provides a variety of commands and shows only these two, with the full tool list living in docs/index.md.

The architecture explains the split. The dependency list includes the MCP SDK, along with the Google API client packages for Docs and Drive, the general googleapis package, google-auth-library, @google-cloud/local-auth, @google-apps/chat for Chat, and keytar for credential storage. So the model talks to the extension over MCP, the extension talks to the Workspace APIs over OAuth, and the slash commands are the surface where you can pin an operation down instead of hoping the model picks the right one.

For an engineer, that last distinction is the practical one. Prompting for something and running a named command are not equally auditable.

Installing the extension and running the first command

Installation is a single command run from your terminal, taken from the project documentation:

gemini extensions install https://github.com/gemini-cli-extensions/workspace

The extension is then available in the CLI. A first real use is a search across your own Drive, or a schedule lookup, issued as a slash command rather than a free-form prompt. The documented forms are /calendar:get-schedule, which takes an optional date and shows your schedule for today or for a specified date, and /drive:search, which takes a query and searches Google Drive for files matching it. There is no configuration file to edit and no API key to paste, because the authentication is the account you are already signed into.

The flow after install is therefore: log in to Google in the browser, install the extension, then ask for something small first. Starting with a read-only operation such as a Drive search is the sensible order, because it confirms that the OAuth grant and the MCP connection work before you let the same connection write to a document.

Headless login keeps credentials away from the model context

Remote environments break the obvious login flow, and the project has a specific answer for that. If you are using the extension over SSH, WSL, Cloud Shell or another environment without a local browser, the documentation points to a headless login tool:

npm run auth-utils -- login

What happens next is the security-relevant part. The command prints an OAuth URL that you can open in any browser, on a local machine or a phone, and after signing in you paste the credentials JSON back into the CLI. The documentation states that credentials are read securely from /dev/tty and are never exposed to the AI model.

That last clause is what separates this design from a flow where a token ends up pasted into the conversation. Reading from the terminal device means the secret passes through the terminal rather than through the prompt, so the model never sees the credential material. Details live in the development docs under the headless and remote environments section.

One caveat to keep in mind: the credential JSON is pasted into the CLI by you, so the security property depends on the paste never landing in a shell history file, a screen share or a terminal log. The tooling cannot protect you from how you copy the secret.

Read, modify and delete is the documented blast radius

The project puts a section titled Important security consideration near the top of its documentation, on indirect prompt injection risk, and it is the most useful thing in the repository for anyone evaluating the extension.

The reasoning runs as follows. Exposing any language model to untrusted data carries the risk of an indirect prompt injection attack, and agentic tools like Gemini CLI connected to MCP servers have access to a wide array of tools and APIs. This server in particular can read, modify and delete Google Account data, and data shared with you.

From that, the guidance is a list of hard rules: never use this with untrusted tools, never include untrusted inputs in the model context, which includes asking Gemini CLI to process mail, documents or other resources from unverified sources, and always carefully review the actions the CLI takes on your behalf. The stated danger is that untrusted inputs may contain hidden instructions that hijack the CLI session, after which an attacker can modify, steal or destroy data.

That last rule is the one that bites in practice. Reading your own inbox is fine on its own, but an email from a stranger is untrusted input by definition, and an agent that can act on Docs and Drive turns a hidden instruction in that email into a destructive action on your account.

Hosting the backend yourself instead of using the hosted one

The deployment section points at a GCP Recreation Guide, docs/GCP-RECREATION.md, for anyone who wants to host their own version of the extension infrastructure. The repository carries a cloud_function directory, which is a hint about the shape of that infrastructure, and the dependency on @google-cloud/local-auth and keytar points to a cloud deployment with credential handling rather than a purely local process.

The alternative approach for a team is to skip this extension and drive the Workspace APIs from your own MCP server or a direct script, keeping the OAuth client, the scope set and the audit trail inside systems your organisation already controls. The difference in approach is where trust lives. This extension is a general purpose bridge that exposes a broad set of Workspace capabilities to a model agent, and its own documentation says so. A script you wrote yourself exposes exactly the operations you chose to implement, with no natural language path to the other ones.

Neither route removes the prompt injection problem, since both eventually let a model act on text it read. The difference is blast radius, which in this case is defined by which tools and which scopes exist.

Weekly preview releases and an Apache 2.0 licence

The repository is not archived and the last push was on 2026-10-19. The release list is a series of weekly preview builds, preview-2026-10-19, preview-2026-10-12 and preview-2026-10-05, each tagged Weekly Preview.

Weekly preview tags mean there is no stable version to pin in the way you would pin a library release. The distribution is dated snapshots that change every week, so teams using this in production need to decide for themselves whether to pin a specific preview tag and update on a schedule, or to track the latest. The version field in package.json reads 0.0.8, which is consistent with an extension that has not settled into a stable release line.

The licence is Apache License 2.0 with the LICENSE file at the root, alongside a SECURITY.md, CONTRIBUTING.md and links to the Google Terms of Service and Privacy Policy, since the extension acts on a Google account rather than on your own infrastructure. Apache 2.0 is permissive and adds an explicit patent grant, so there is no separate commercial condition to weigh here. That is different from several other AI tooling projects that add a maintenance fee on top of an open source licence, and it makes the legal question here narrower: it is about what Google terms say about programmatic access to your account, not about the extension's own terms.

Editorial conclusion

Adopt the Workspace extension if you personally want Gemini CLI to act on your own Google account and you are willing to review what it does with the account, since the extension can read, modify and delete your Google data and the project documents that reach. Do not point it at shared mailboxes, documents from unverified senders or any agent run with other untrusted tools, which is the exact scenario the project warns about. Before installing, read docs/index.md for the tool list, confirm you can complete the OAuth flow in a browser on the same machine, and check whether you can host the infrastructure yourself through docs/GCP-RECREATION.md if your organisation cannot send Workspace traffic to a public endpoint.

Frequently asked questions

Official sources

1. gemini-cli-extensions/workspace on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases