googleworkspace/cli

The problem

Anyone automating Google Workspace ends up writing the same glue: OAuth flows, client libraries or curl calls against the REST docs, pagination loops, and per-endpoint JSON shaping. The API surface is huge and each service has its own quirks, so tooling gets rebuilt in every language and every repo. gws collapses that into one binary that reads Google's Discovery Service at runtime and exposes every method as a command that returns structured JSON.

What's different

Most teams either use Google's official client libraries or hand-rolled curl wrappers. Client libraries are idiomatic but language-bound and still require you to model request/response types; curl scripts have no schema awareness and no pagination. gws sits in between: its command surface is generated from Discovery, so new endpoints appear without a release, gws schema exposes the request/response schema for any method, and --dry-run plus auto-pagination and NDJSON streaming make it shell-friendly. The other differentiator is the bundled agent skills — SKILL.md files per API plus curated recipes — so an LLM agent can drive Workspace without custom tooling. That is a positioning choice, not a capability the official libraries offer.

Who it's for

Developers and ops people who script Workspace from shell, CI or a server, and anyone building an agent that needs Drive, Gmail, Calendar, Sheets, Docs or Admin access. It is a good fit if you already have a Google Cloud project and can live with OAuth setup. Look elsewhere if you need typed bindings inside a single application codebase, or if you cannot obtain OAuth credentials — this does not remove that requirement. Enterprise admins wanting managed, audited access should also weigh that this is not an officially supported Google product.

Cost of adoption

You need a Google Cloud project and OAuth client, plus Node.js 18+ if you install via npm; pre-built binaries exist for other paths, and the README also documents cargo, Homebrew and Nix. Auth is the real friction: testing-mode apps cap consent at roughly 25 scopes, and the README warns the recommended preset with 85+ scopes will fail for unverified apps, so scope selection is on you. Credentials are encrypted at rest with a key in the OS keyring, but a file backend exists as a fallback. The project explicitly says to expect breaking changes before v1.0, and the README is long and detailed enough to be the real starting point — trust it over this summary.

Verdict

The repo is young (created March 2026) but already at ~31.8k stars and a top-15 weekly Rust entry with +274, plus a 953-point Hacker News thread at launch — that is a strong spike rather than a long track record, and it has not appeared on the daily board. The Discovery-driven design is genuinely the right abstraction for an API this broad, and the agent-skill packaging is well timed. Treat it as promising and fast-moving, not stable: pin a version if you put it in CI, and expect churn until v1.0.