Better this than a Google dashboard, or slopped together third party libs. I know Google says they don't support it, but they'll probably support it better than someone outside of Google can support it.
[1] https://workspaceupdates.googleblog.com/2025/12/workspace-st...
Their Github releases provides the binaries, as well as a `curl ... | sh` install method and a guide to use github releases attestation which I liked.
The install script checks the OS and Arch, and pulls the right Rust binary.
Then, they get upgrade mechanism out of the box too, and an uninstall mechanism.
NPM has become the de facto standard for installing any software these days, because it is present on every OS.
if you build for the web, no matter what your backend is (python, go, rust, java, c#), your frontend will almost certainly have some js, so likely you need npm.
That's the arbitrary code execution at install time aspect of npm that developers should be extra wary of in this day and age. Saner node package managers like pnpm ignore the build script and you have to explicitly approve it on a case-by-case basis.
That said, you can execute code with build.rs with cargo too. Cargo is just not a build artifact distribution mechanism.
Honestly I’m shocked to see so many people supporting this
When I use apt-get, I have no idea what languages the packages were written in.
npm install -g @googleworkspace/cli
gws auth setup
{ "error": { "code": 400, "message": "gcloud CLI not found. Install it from https://cloud.google.com/sdk/docs/install", "reason": "validationError" } }
Which takes you to...
https://docs.cloud.google.com/sdk/docs/install-sdk
Where you have to download a tarball, extract it and run a shell script.
I mean how hard is it to just imitate everyone else out there and make it a straight up npm install?
The contributors are a Google DRE, 5 bots / automating services, and a dev in Canada.
Eh, enjoy it while it lasts. Companies are still trying to figure out how to get value by ketting a thousand flowers blossom. The walled-garden gates will swing shut soon enough, just like they did ok the last open access revolutions (semantic web, Web 2.0, etcetera)
I mean it's great that we get this, hopefully it can continue to be maintained and I'd love to see a push for similar stuff for other products and at other companies.
i’d rather not waste the context tokens re implementing their cli from scratch, if indeed it does a good job.
- No need to worry about transport layer stuff at all, including auth or headers. This is baked in, so saves context.
- They are self describing with --help and then nested --help commands, way better than trying to decipher an OpenAPI spec. You usually don't even need an agent skill, just call the --help and the LLM figures it out.
Remember this repo is not an agent. It's just a cli tool to operate over gsuite documents that happens to have an MCP command and a bunch of skills prebundled.
That's a new one. I guess the hope is agents are good at navigating cli and it also democratizes the ecosystem to be used by any agent as opposed to Microsoft (which only allows Copilot to work in its ecosystem)
Probably someone's hobby project or 20% time at best.
> requires setting up gcloud cli first, necessitates making a Google Cloud project
cmon google how come even your attempts at good ux start out with bad ux? let me just oauth with my regular google account like every other cli tool out there. gh cli, claude, codex - all are a simple “click ok” in the browser to log in. wtf.
and the slow setup - i need to make my own oauth app & keys??
EDIT: oh yeah and get my oath app verified all so i can use it with my own account
Multiple errors and issues along the way, now I'm on `gws auth login`, and trying to pick the oAuth scopes. I go ahead and trust their defaults and select `recommended`, only to get a warning that this is too many scopes and may error out (then why is this the recommended setting??), and then yeah, it errors out when trying to authenticate in the browser.
The error tells me I need to verify my app, so I go to the app settings in my cloud console and try to verify and there's no streamlined way to do this. It seems the intended approach is for me to manually add, one by one, each of the 85 scopes that are on the "recommended" list, and then go through the actual verification.
Have the people that built and released this actually tried to install and run this, just a single time, purely following their own happy path?
It’s a very different experience than AWS though and takes some getting used to.
It wild that this process is still so challenging. There's got to be some safe streamlined way that sets up an app identity you own that can only use to access your own account.
My guess is that organizationally within Google, the developer app authorization process must have many teams involved in its implementation and many other outside stakeholders. A single unified team wouldn't responsible for this confusion and complexity. I get why... it's a huge source of bad actors. But there's got to be a better way.
sega_sai•2h ago
jryio•2h ago
joeconway•2h ago
> This is not an officially supported Google product.
Lermatroid•2h ago
dotancohen•2h ago
garciasn•2h ago
jpoehnelt/README.md
About
I am a Developer Relations Engineer at Google. Currently I am on the Google Workspace DevRel team and was on the Google Maps Platform before that. Previously I worked at Descartes Labs and the US Geological Survey.
Check out my website at https://justin.poehnelt.com.
dotancohen•25m ago
cvhc•2h ago
tfsh•43m ago
spankalee•2h ago