Google Workspace CLI

Original Article ↗ Hacker News Discussion ↗

Google has released an open source, Rust-based Google Workspace CLI that dynamically maps its command surface from the company’s existing APIs, aiming to serve AI agents and automation as much as human terminal users. Commenters welcome a first-party alternative to tools like GAM and gog and see it as part of a broader trend toward CLIs as a more agent-friendly interface than MCP servers or raw HTTP APIs, but many criticize the reliance on gcloud, OAuth apps, and complex permissioning that make setup painful, especially for non-experts. There is also skepticism about long-term support, given the project’s DevRel origins and “not an officially supported Google product” disclaimer, as well as perennial concerns about Google’s habit of abandoning tools once developers come to rely on them.

Project status & trust

  • Repo is under a Google Workspace org and contributors appear to be Google employees, but README says “not an officially supported Google product.”
  • Some treat that as “likely safe re: TOS but low support / maintenance,” comparing it to typical DevRel/sample projects that can be abandoned.
  • Others worry that any GitHub org can look “official,” raising phishing/supply-chain concerns, though this org appears legitimately tied to Google.

Positioning vs existing tools (GAM, gog, etc.)

  • Seen as Google’s answer to third‑party Workspace CLIs like GAM and gog.
  • Difference highlighted: GAM is admin‑focused for Workspace domains; this CLI appears more user‑API focused, akin to gog.
  • Some note GAM is already widely present in training data, so agents may reach for it more reliably today.

Installation & packaging (npm, Rust, gcloud)

  • CLI is written in Rust but primarily distributed via npm. Many find this strange:
    • Supporters: npm is widely installed, auto‑selects OS/arch, manages upgrades/uninstalls.
    • Critics: npm isn’t an OS‑level package manager, adds another tool to install, and has supply‑chain risks.
  • Alternative install paths exist (curl | sh, GitHub releases, cargo‑like tools), which some prefer.
  • Users complain that “quick setup” actually requires installing gcloud, creating a GCP project, enabling APIs, and configuring OAuth—described as confusing and slow.

Auth, permissions, and UX pain

  • Major recurring theme: Google Cloud OAuth and permissions remain the primary barrier.
  • Reported issues:
    • Need to create and possibly verify an OAuth app, select many scopes, and deal with errors when using “recommended” scopes.
    • Confusing Console flows, especially for personal accounts and non‑technical users.
  • Several say this is the same long‑standing pain with all Google APIs; CLI doesn’t solve it.

AI agents, CLIs & MCP

  • Author explicitly designed the CLI “for agents first”; human usability is almost a side effect.
  • Many see CLIs as better than MCP for agents:
    • Self‑describing via --help; no need to manage HTTP headers/auth in prompts.
    • Lower token usage and simpler integration with existing shells and scripts.
  • Others argue robust HTTP APIs + OpenAPI or discovery services already solve this, and MCP/extra layers are hype.

Dynamic command surface & capabilities

  • CLI dynamically generates commands from Google’s Discovery Service at runtime.
  • Some find this clever for agents but frustrating for humans because there’s no static, complete command list or docs.
  • Questions remain about rate‑limit handling, retries, Drive browsing, and support for personal Gmail accounts; some of these are explicitly reported as not working yet.