gws

One CLI for all of Google Workspace — built for humans and AI agents.
Drive, Gmail, Calendar, and every Workspace API. Zero boilerplate. Structured JSON output. 40+ agent skills included.

⬇️ Download the latest release for your OS

gws doesn't ship a static list of commands. It reads Google's own Discovery Service at runtime and builds its entire command surface dynamically. When Google Workspace adds an API endpoint or method, gws picks it up automatically.

• Prerequisites
• Installation
• Quick Start
• Why gws?
• Authentication
• AI Agent Skills
• Advanced Usage
• Environment Variables
• Exit Codes
• Architecture
• Troubleshooting
• Development
• Maintenance status

• A Google Cloud project — required for OAuth credentials. You can create one via the Google Cloud Console or with the gcloud CLI or with the gws auth setup command.
• A Google account with access to Google Workspace
• Rust toolchain — only if building from source

The recommended way to install gws is to download the pre-built binary for your OS and architecture from the GitHub Releases page. Extract the archive and place the gws binary in your $PATH.

Build from source with cargo:

cargo install --git https://github.com/CruGlobal/gws-cli --locked

A Nix flake is also available:

nix run github:CruGlobal/gws-cli

gws auth setup     # walks you through Google Cloud project config
gws auth login     # subsequent OAuth login
gws drive files list --params '{"pageSize": 5}'

For humans — stop writing curl calls against REST docs. gws gives you --help on every resource, --dry-run to preview requests, and auto‑pagination.

For AI agents — every response is structured JSON. Pair it with the included agent skills and your LLM can manage Workspace without custom tooling.

# List the 10 most recent files
gws drive files list --params '{"pageSize": 10}'

# Create a spreadsheet
gws sheets spreadsheets create --json '{"properties": {"title": "Q1 Budget"}}'

# Send a Chat message
gws chat spaces messages create \
  --params '{"parent": "spaces/xyz"}' \
  --json '{"text": "Deploy complete."}' \
  --dry-run

# Introspect any method's request/response schema
gws schema drive.files.list

# Stream paginated results as NDJSON
gws drive files list --params '{"pageSize": 100}' --page-all | jq -r '.files[].name'

--dry-run prints the request instead of sending it. Helper (+verb) commands that don't support it yet (e.g. gmail +watch, workflow +file-announce, workflow +email-to-task, modelarmor +create-template) exit with a validation error instead of making changes. Read-only helpers (e.g. calendar +agenda, gmail +triage) still run normally under --dry-run.

The CLI supports multiple auth workflows so it works on your laptop, in CI, and on a server.

Credentials are encrypted at rest (AES-256-GCM) with the key stored in your OS keyring (or ~/.config/gws/.encryption_key when GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file).

gws auth setup       # one-time: creates a Cloud project, enables APIs, logs you in
gws auth login       # subsequent scope selection and login

gws auth setup requires the gcloud CLI. If you don't have gcloud, use the manual setup below instead.

gws auth login -s drive,gmail,sheets

Use this when gws auth setup cannot automate project/client creation, or when you want explicit control.

1. Open Google Cloud Console in the target project:
   • OAuth consent screen: https://console.cloud.google.com/apis/credentials/consent?project=<PROJECT_ID>
   • Credentials: https://console.cloud.google.com/apis/credentials?project=<PROJECT_ID>
2. Configure OAuth branding/audience if prompted:
   • App type: External (testing mode is fine)
3. Add your account under Test users
4. Create an OAuth client:
   • Type: Desktop app
5. Download the client JSON and save it to:
   • ~/.config/gws/client_secret.json

Then run:

gws auth login

You can complete OAuth either manually or with browser automation.

• Human flow: run gws auth login, open the printed URL, approve scopes.
• Agent-assisted flow: the agent opens the URL, selects account, handles consent prompts, and returns control once the localhost callback succeeds.

If consent shows "Google hasn't verified this app" (testing mode), click Continue. If scope checkboxes appear, select required scopes (or Select all) before continuing.

1. Complete interactive auth on a machine with a browser.
2. Export credentials:

   gws auth export --unmasked > credentials.json

3. On the headless machine:

   export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/path/to/credentials.json
   gws drive files list   # just works

Point to your key file; no login needed.

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/path/to/service-account.json
gws drive files list

Useful when another tool (e.g. gcloud) already mints tokens for your environment.

export GOOGLE_WORKSPACE_CLI_TOKEN=$(gcloud auth print-access-token)

Environment variables can also live in a .env file in the current directory. See .env files.

For deployments that sit behind a credential-injecting network proxy — e.g. gapx's principal-bound grants, fronted by an Agent Proxy that strips any client-set Authorization header and injects its own — set:

export GOOGLE_WORKSPACE_CLI_AUTH=none

With this set, gws skips credential loading and token acquisition entirely (any GOOGLE_WORKSPACE_CLI_TOKEN, credentials file, or ADC is ignored) and sends every request with no Authorization header — not an empty bearer token. Trust lives entirely in the network path; the proxy is expected to authenticate the request. gws auth status reports "auth_method": "none" in this mode rather than inspecting local credential files.

Typically paired with GOOGLE_WORKSPACE_CLI_DISCOVERY_BASE_URL (see Environment Variables) so both discovery documents and API calls route through the proxy.

With GOOGLE_WORKSPACE_CLI_DISCOVERY_BASE_URL set, every API request, including helper commands like +agenda and +triage, goes to the rootUrl in the proxy's discovery documents. gws refuses to connect to *.googleapis.com directly, so a request that would skip the proxy fails instead. Exceptions: oauth2.googleapis.com and the userinfo lookup during gws auth commands, and Model Armor's regional endpoints (*.rep.googleapis.com). If the override is set without GOOGLE_WORKSPACE_CLI_AUTH=none, gws warns on stderr that access tokens will be sent to the proxy.

Before sending an API request, gws checks the host that the discovery document's rootUrl/baseUrl points at. With the override set, the scheme, host and port must match the override URL. Without it, the URL must be https on googleapis.com or a subdomain. Anything else fails with a discovery error and nothing is sent. This also covers tampered files in the discovery cache. The *.googleapis.com connect guard above only blocks Google hosts; it is not an egress control and does not limit traffic to the proxy host.

The repo ships 100+ Agent Skills (SKILL.md files) — one for every supported API, plus higher-level helpers for common workflows and 50 curated recipes for Gmail, Drive, Docs, Calendar, and Sheets. See the full Skills Index for the complete list.

# Install all skills at once
npx skills add https://github.com/CruGlobal/gws-cli

# Or pick only what you need
npx skills add https://github.com/CruGlobal/gws-cli/tree/main/skills/gws-drive
npx skills add https://github.com/CruGlobal/gws-cli/tree/main/skills/gws-gmail

# Symlink all skills (stays in sync with repo)
ln -s $(pwd)/skills/gws-* ~/.openclaw/skills/

# Or copy specific skills
cp -r skills/gws-drive skills/gws-gmail ~/.openclaw/skills/

1. Authenticate the CLI first:

   gws auth setup

2. Install the plugin into Antigravity CLI:

   agy plugin install https://github.com/CruGlobal/gws-cli

   Still on Gemini CLI (enterprise license or paid API key)? The extension still works:

   gemini extensions install https://github.com/CruGlobal/gws-cli

Installing this plugin gives your Antigravity CLI agent direct access to all gws commands and Google Workspace agent skills. Because gws handles its own authentication securely, you simply need to authenticate your terminal once prior to using the agent, and the plugin will automatically inherit your credentials.

gws drive files create --json '{"name": "report.pdf"}' --upload ./report.pdf

Sheets ranges use ! which bash interprets as history expansion. Always wrap values in single quotes:

# Read cells A1:C10 from "Sheet1"
gws sheets spreadsheets values get \
  --params '{"spreadsheetId": "SPREADSHEET_ID", "range": "Sheet1!A1:C10"}'

# Append rows
gws sheets spreadsheets values append \
  --params '{"spreadsheetId": "ID", "range": "Sheet1!A1", "valueInputOption": "USER_ENTERED"}' \
  --json '{"values": [["Name", "Score"], ["Alice", 95]]}'

Some services ship hand-crafted helper commands alongside the auto-generated Discovery surface. Helper commands are prefixed with + so they are visually distinct and never collide with Discovery-generated method names.

Time-aware helpers (+agenda, +standup-report, +weekly-digest, +meeting-prep) automatically use your Google account timezone (fetched from Calendar Settings API and cached for 24 hours). Override with --timezone/--tz on +agenda, or set the --timezone flag for explicit control.

Run gws <service> --help to see both Discovery methods and helper commands together.

gws gmail --help      # shows +send, +reply, +reply-all, +forward, +triage, +watch …
gws calendar --help   # shows +insert, +agenda …
gws drive --help      # shows +upload …

Full helper reference:

Examples:

# Send an email
gws gmail +send --to alice@example.com --subject "Hello" --body "Hi there"

# Reply to a message
gws gmail +reply --message-id MESSAGE_ID --body "Thanks!"

# Append a row to a spreadsheet
gws sheets +append --spreadsheet SPREADSHEET_ID --values "Alice,95"

# Show today's calendar agenda
gws calendar +agenda

# Upload a file to Drive
gws drive +upload ./report.pdf --name "Q1 Report"

# Morning standup summary
gws workflow +standup-report

# Show today's agenda in a specific timezone
gws calendar +agenda --today --timezone America/New_York

Integrate Google Cloud Model Armor to scan API responses for prompt injection before they reach your agent.

gws gmail users messages get --params '...' \
  --sanitize "projects/P/locations/L/templates/T"

In block mode, output is suppressed and the command exits non-zero when Model Armor finds a match. It also blocks when the Model Armor call itself fails (network, quota, bad template), so unchecked content never passes through. warn mode logs the failure and continues.

All variables are optional. See .env.example for a copy-paste template.

gws loads a .env file from the current directory only (parent directories are not searched). Variables already set in your shell win over the file. The file is trusted like your shell environment, so only run gws in directories whose .env you trust.

If the file sets a variable that changes where requests go or which credentials are used (any GOOGLE_WORKSPACE_CLI_* variable except LOG, LOG_FILE and SANITIZE_MODE, plus GOOGLE_APPLICATION_CREDENTIALS, proxy and TLS certificate variables), gws prints a warning naming those variables (never their values).

GOOGLE_WORKSPACE_CLI_DOTENV controls this:

Set it in your shell profile; a value inside .env itself is ignored.

gws uses structured exit codes so scripts can branch on the failure type without parsing error output.

gws drive files list --params '{"fileId": "bad"}'
echo $?   # 1 — API error

gws unknown-service files list
echo $?   # 3 — validation error (unknown service)

gws uses a two-phase parsing strategy:

1. Read argv[1] to identify the service (e.g. drive)
2. Fetch the service's Discovery Document (cached 24 h)
3. Build a clap::Command tree from the document's resources and methods
4. Re-parse the remaining arguments
5. Authenticate, build the HTTP request, execute

All output — success, errors, download metadata — is structured JSON.

Your OAuth app is in testing mode and your account is not listed as a test user.

Fix: Open the OAuth consent screen in your GCP project → Test users → Add users → enter your Google account email. Then retry gws auth login.

Expected when your app is in testing mode. Click Advanced → Go to <app name> (unsafe) to proceed. This is safe for personal use; verification is only required to publish the app to other users.

Unverified (testing mode) apps are limited to ~25 OAuth scopes. The recommended scope preset includes many scopes and will exceed this limit.

Fix: Select only the scopes you need:

gws auth login --scopes drive,gmail,calendar

gws auth setup requires the gcloud CLI to automate project creation. You have three options:

1. Install gcloud and use gcloud directly.
2. Re-run gws auth setup which wraps gcloud calls.
3. Skip gcloud entirely — set up OAuth credentials manually in the Cloud Console

The OAuth client was not created as a Desktop app type. In the Credentials page, delete the existing client, create a new one with type Desktop app, and download the new JSON.

If a required Google API is not enabled for your GCP project, you will see a 403 error with reason accessNotConfigured:

{
  "error": {
    "code": 403,
    "message": "Gmail API has not been used in project 549352339482 ...",
    "reason": "accessNotConfigured",
    "enable_url": "https://console.developers.google.com/apis/api/gmail.googleapis.com/overview?project=549352339482"
  }
}

gws also prints an actionable hint to stderr:

💡 API not enabled for your GCP project.
   Enable it at: https://console.developers.google.com/apis/api/gmail.googleapis.com/overview?project=549352339482
   After enabling, wait a few seconds and retry your command.

Steps to fix:

1. Click the enable_url link (or copy it from the enable_url JSON field).
2. In the GCP Console, click Enable.
3. Wait ~10 seconds, then retry your gws command.

To see which APIs are already enabled: gcloud services list --enabled --project <PROJECT_ID>.

cargo build                       # dev build
cargo clippy -- -D warnings       # lint
cargo test                        # unit tests
./scripts/coverage.sh             # HTML coverage report → target/llvm-cov/html/

This is a community-maintained fork of googleworkspace/cli, maintained by Cru primarily for our own use. We publish it openly so our changes are available to others, but:

• Best-effort, no SLA. Fixes are prioritized over features; we merge what we have time for.
• Internal-first. Changes are driven by what Cru needs; we may not adopt every feature request.
• Issues and PRs are welcome, but triage may be slow. Bug-fix PRs are far more likely to land than large features.
• The CLI auto-updates its command surface from Google's Discovery Service at runtime, so it keeps working as Workspace APIs change without code changes here.

If a more active community successor emerges, we may converge on it.

Apache-2.0. This is a fork of the original googleworkspace/cli by Google LLC. Upstream copyright and license notices are retained; see LICENSE and NOTICE.