gws (HODL1 Fork)

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.

Important

Temporarily disabling non-collaborator pull requests. See this discussion, googleworkspace#249.

Note

This is a fork of googleworkspace/cli maintained by HODL1 (kushim-team). This is not an officially supported Google product.

Fork Branch Strategy

This repository is a fork of googleworkspace/cli with the following branch strategy:

Branch	Purpose
main	Kept in sync with upstream googleworkspace/cli main. No custom changes.
custom	All HODL1-specific changes are developed here.

Syncing with upstream

git fetch upstream
git checkout main
git merge upstream/main
git checkout custom
git merge main

Upstream updates are merged (not rebased) into custom to preserve a clean, shared-friendly history.

npm install -g @googleworkspace/cli

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.

Important

This project is under active development. Expect breaking changes as we march toward v1.0.

Contents

• Prerequisites
• Installation
• Quick Start
• Why gws?
• Authentication
• AI Agent Skills
• MCP Server
  • Permission Control
• Advanced Usage
• Environment Variables
• Architecture
• Troubleshooting
• Development

Prerequisites

• Node.js 18+ — for npm install (or download a pre-built binary from GitHub Releases)
• 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

Installation

npm install -g @googleworkspace/cli

The npm package bundles pre-built native binaries for your OS and architecture. No Rust toolchain required.

Pre-built binaries are also available on the GitHub Releases page.

Or build from source:

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

A Nix flake is also available at github:googleworkspace/cli

nix run github:googleworkspace/cli

Quick Start

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

Why gws?

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'

Authentication

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

Which setup should I use?

I have…	Use
gcloud installed and authenticated	gws auth setup (fastest)
A GCP project but no gcloud	Manual OAuth setup
An existing OAuth access token	GOOGLE_WORKSPACE_CLI_TOKEN
Existing Credentials	GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE

Interactive (local desktop)

Credentials are encrypted at rest (AES-256-GCM) with the key stored in your OS keyring.

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.

Warning

Scope limits in testing mode: If your OAuth app is unverified (testing mode), Google limits consent to ~25 scopes. The recommended scope preset includes 85+ scopes and will fail for unverified apps (especially for @gmail.com accounts). Choose individual services instead to filter the scope picker:

gws auth login -s drive,gmail,sheets

Manual OAuth setup (Google Cloud Console)

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

Important

You must add yourself as a test user. In the OAuth consent screen, click Test users → Add users and enter your Google account email. Without this, login will fail with a generic "Access blocked" error.

Then run:

gws auth login

Browser-assisted auth (human or agent)

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.

Headless / CI (export flow)

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

Service Account (server-to-server)

Point to your key file; no login needed.

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

Pre-obtained Access Token

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

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

Precedence

Priority	Source	Set via
1	Access token	GOOGLE_WORKSPACE_CLI_TOKEN
2	Credentials file	GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE
3	Encrypted credentials	gws auth login
4	Plaintext credentials	~/.config/gws/credentials.json

Environment variables can also live in a .env file.

AI Agent Skills

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/googleworkspace/cli

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

OpenClaw setup

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

The gws-shared skill includes an install block so OpenClaw auto-installs the CLI via npm if gws isn't on PATH.

Gemini CLI Extension

1. Authenticate the CLI first:

   gws auth setup

2. Install the extension into the Gemini CLI:

   gemini extensions install https://github.com/googleworkspace/cli

Installing this extension gives your Gemini 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 extension will automatically inherit your credentials.

MCP Server

gws mcp starts a Model Context Protocol server over stdio, exposing Google Workspace APIs as structured tools that any MCP-compatible client (Claude Desktop, Gemini CLI, VS Code, etc.) can call.

gws mcp -s drive                  # expose Drive tools
gws mcp -s drive,gmail,calendar   # expose multiple services
gws mcp -s all                    # expose all services (many tools!)

Configure in your MCP client:

{
  "mcpServers": {
    "gws": {
      "command": "gws",
      "args": ["mcp", "-s", "drive,gmail,calendar"]
    }
  }
}

Tip

Each service adds roughly 10–80 tools. Keep the list to what you actually need to stay under your client's tool limit (typically 50–100 tools).

Flag	Description
-s, --services <list>	Comma-separated services to expose, or all
-w, --workflows	Also expose workflow tools
-e, --helpers	Also expose helper tools
--permissions-file <path>	Path to permissions YAML (env: GWS_PERMISSIONS_FILE)

Permission Control (HTTP Gateway)

When running in HTTP transport mode as a multi-user gateway, you can restrict access per user by providing a YAML permissions file. The permission system uses a two-layer model — both layers are always checked:

1. OAuth scopes — controls which Google API scopes the role can use.
2. Method patterns — controls which specific API methods are allowed.

A request is permitted only when it passes both checks. Roles must define both scopes and method; if either is empty the role denies all access.

gws mcp -s all -t http \
  --oauth-client-id $CLIENT_ID \
  --gateway-base-url https://gw.example.com \
  --permissions-file config/permissions.yaml

Or via environment variable:

export GWS_PERMISSIONS_FILE=config/permissions.yaml

YAML format

# config/permissions.yaml

roles:
  admin:
    # Primary: which OAuth scopes this role can use
    scopes:
      - "https://www.googleapis.com/auth/drive"
      - "https://www.googleapis.com/auth/gmail.readonly"
      - "https://www.googleapis.com/auth/calendar"
      - "https://www.googleapis.com/auth/spreadsheets"
      - "https://www.googleapis.com/auth/documents"
      - "https://www.googleapis.com/auth/presentations"
      - "https://www.googleapis.com/auth/tasks"
    # Secondary (optional): further restrict to specific methods
    method:
      - "drive.files.list"
      - "drive.files.get"
      - "drive.files.create"
      # ...

  reader:
    scopes:
      - "https://www.googleapis.com/auth/drive.readonly"
      - "https://www.googleapis.com/auth/gmail.readonly"
      - "https://www.googleapis.com/auth/calendar.readonly"
    method:
      - "drive.files.list"
      - "drive.files.get"
      - "gmail.users.messages.list"
      - "calendar.events.list"
      # ...

users:
  admin@company.com:
    role: admin
  reader@company.com:
    role: reader

How the two layers work

Both scopes and method are always checked. A request is allowed only when:

1. At least one of the method's required OAuth scopes is present in the role's scopes
2. The method ID matches at least one of the role's method patterns

If either scopes or method is empty/missing in the role definition, the role denies all access.

Example: A role with drive.readonly scope and method: ["drive.files.list", "drive.files.get"] can call those two methods (both accept drive.readonly) but cannot call drive.files.create (not in method list) or gmail.users.messages.list (scope mismatch).

OAuth scope narrowing

When a permissions file is loaded, the gateway automatically narrows the OAuth consent screen to only request the union of all role scopes (plus openid email profile). This applies the principle of least privilege — the gateway token only carries scopes that at least one role needs.

You can override this by explicitly setting --oauth-scopes:

# Auto-narrowed from permissions (recommended)
gws mcp -s all -t http --permissions-file config/permissions.yaml ...

# Manual override (ignores permissions scopes)
gws mcp -s all -t http --oauth-scopes "openid email profile https://www.googleapis.com/auth/drive" ...

Important

Token-level downscoping is not possible for Google Workspace APIs. Google's Credential Access Boundary (CAB) only supports Cloud Storage. The gateway enforces scope restrictions at the application layer — the OAuth token itself carries the union of all role scopes, but the gateway blocks requests to methods outside the user's permitted scopes.

Scope reference

Common Google Workspace OAuth scopes:

Scope	Access level
https://www.googleapis.com/auth/drive	Full Drive access
https://www.googleapis.com/auth/drive.readonly	Read-only Drive access
https://www.googleapis.com/auth/gmail.modify	Read/write Gmail (no send/delete)
https://www.googleapis.com/auth/gmail.readonly	Read-only Gmail
https://www.googleapis.com/auth/calendar	Full Calendar access
https://www.googleapis.com/auth/calendar.readonly	Read-only Calendar
https://www.googleapis.com/auth/spreadsheets	Full Sheets access
https://www.googleapis.com/auth/spreadsheets.readonly	Read-only Sheets
https://www.googleapis.com/auth/documents	Full Docs access
https://www.googleapis.com/auth/documents.readonly	Read-only Docs
https://www.googleapis.com/auth/presentations	Full Slides access
https://www.googleapis.com/auth/presentations.readonly	Read-only Slides
https://www.googleapis.com/auth/tasks	Full Tasks access
https://www.googleapis.com/auth/tasks.readonly	Read-only Tasks

Each API method declares which scopes it accepts in the Discovery Document. For example, drive.files.list accepts both drive and drive.readonly. The method is allowed if the role has at least one of the method's accepted scopes.

Method patterns

Method IDs follow the naming from Google's Discovery JSON (e.g. drive.files.list, gmail.users.messages.send). You can inspect available method IDs with gws schema <method_id>.

Pattern	Matches
*	All methods across all services
gmail.*	All Gmail methods
gmail.users.messages.*	All Gmail message methods (list, get, send, etc.)
drive.files.list	Exact match only

Behavior

• HTTP mode only — OAuth authentication and permission control are only supported in HTTP transport mode (-t http). In stdio mode these options are ignored (a warning is printed).
• Unregistered users (email not in users:) are denied all access — tools/list returns an empty list and tools/call returns a permission error.
• No permissions file — all authenticated users have full access (backwards-compatible).
• Missing scopes or method in role — the role denies all access. Both must be defined.

Advanced Usage

Multipart Uploads

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

Pagination

Flag	Description	Default
--page-all	Auto-paginate, one JSON line per page (NDJSON)	off
--page-limit <N>	Max pages to fetch	10
--page-delay <MS>	Delay between pages	100 ms

Google Sheets — Shell Escaping

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]]}'

Model Armor (Response Sanitization)

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"

Variable	Description
GOOGLE_WORKSPACE_CLI_SANITIZE_TEMPLATE	Default Model Armor template
GOOGLE_WORKSPACE_CLI_SANITIZE_MODE	warn (default) or block

Environment Variables

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

Variable	Description
GOOGLE_WORKSPACE_CLI_TOKEN	Pre-obtained OAuth2 access token (highest priority)
GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE	Path to OAuth credentials JSON (user or service account)

| GOOGLE_WORKSPACE_CLI_CLIENT_ID | OAuth client ID (alternative to client_secret.json) | | GOOGLE_WORKSPACE_CLI_CLIENT_SECRET | OAuth client secret (paired with CLIENT_ID) | | GOOGLE_WORKSPACE_CLI_CONFIG_DIR | Override config directory (default: ~/.config/gws) | | GOOGLE_WORKSPACE_CLI_SANITIZE_TEMPLATE | Default Model Armor template | | GOOGLE_WORKSPACE_CLI_SANITIZE_MODE | warn (default) or block | | GOOGLE_WORKSPACE_PROJECT_ID | GCP project ID override for quota/billing and fallback for helper commands |

Environment variables can also be set in a .env file (loaded via dotenvy).

Architecture

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.

Troubleshooting

"Access blocked" or 403 during login

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.

"Google hasn't verified this app"

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.

Too many scopes / consent screen error

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

gcloud CLI not found

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

redirect_uri_mismatch

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.

API not enabled — accessNotConfigured

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.

Tip

You can also run gws auth setup which walks you through enabling all required APIs for your project automatically.

Development

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

AI-DLC 開発サイクル

本プロジェクト (HODL1 fork) では AI-DLC (AI-Driven Development Life Cycle) に基づく開発サイクルを採用しています。

各フィーチャーの中間成果物は specs/<feature-name>/ に配置します。

specs/
  remote-mcp-gateway/
    requirements.md   # Inception: 要件定義
    design.md          # Inception → Construction: 設計・決定事項
    tasks.md           # Construction: 実装タスクのブレイクダウン

開発の流れ:

1. Inception — 要件を requirements.md に整理し、設計判断を design.md にまとめる
2. Construction — tasks.md のタスクリストに従い実装する。AI エージェントは specs を読んでコンテキストを得る
3. Operations — デプロイ・運用に関する知見を specs にフィードバックする

新しいフィーチャーを始めるときは specs/<feature-name>/ ディレクトリを作成し、同じ 3 ファイル構成で進めてください。

License

Apache-2.0

Disclaimer

Caution

This is not an officially supported Google product.