alt Hacker NewsGoogle Workspace CLI
Comments
Related, I often work with markdown docs (usually created via CLI agents like Claude Code) and need to collaborate with others in google docs, which is extremely markdown-unfriendly[1], so I built small quality-of-life CLI tools to convert Gdocs -> md and vice versa, called gdoc2md and md2gdoc:
https://pchalasani.github.io/claude-code-tools/integrations/...
They handle embedded images in both directions. There are similar gsheet2csv and csv2gsheet tools in the same repo.
Similar to the posted tool, there is a first time set up involving creating an app, that is documented above.
[1] in the sense there are multiple annoying clicks/steps to get a markdown doc to look good in Gdocs. You'd know the pain if you've tried it.
Interesting post from the main contributor about this (at least I assume it’s what he’s referencing) https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
Generating a good cli isn't all that hard for agentic coding tools. When you do it manually it's highly repetitive work. But all you are doing is low level plumbing. Given some parsed arguments, call a function, return the result (with some formatting, prettying, etc.). In the end it's just a facade for an API, library, or whatever else you want to have a cli for. Easy to write. Easy to test. But manually going through your API resource by resource, parameter by parameter, etc. takes a long time. An LLM just blazes through that in a few minutes. Generate some tests, tweak as needed, and you are good to go.
I did a few CLIs with codex in the last few weeks. I do simple ops with this stuff. I've had a few use cases for new features where previously I would have had to build some kind of quick and dirty admin UI just to use and test a new API feature before being able to integrate it into our product. With a generated cli, I can just play with it from the command line. Or make codex do that for me.
A good cli with a modern command line argument parser, well documented options, bash/zsh auto complete, pretty colors, etc. is generally nice to have. I mapped resources to commands and sub commands, made it add parameters with sensible defaults or optional ones. Then I got lazy and just asked it what else it thought it was missing, it made some suggestions and I gave it the thumbs up and it all got added. I even generated a simple interactive TUI at some point. Because why not? I also made it generate a md skill file explaining how to use the cli that you can just drop in your skills directory.
> Disclaimer
> This is not an officially supported Google product.
Looked like an official Google Product on the first glance.
I was excited to see this but all of that went away when I realized you need to create an app in GCP to use it. Can't really expect non technical users to set this up across the company.
God, getting this set up is frustrating. I've spent 45 minutes trying to get this to work, just following their defaults the whole way through.
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?
What a shame Google Photos have no decent API or CLI. Photos could have been the best SAAS but changes in the API make it terribely unusable.
I wish I could use an API/CLI to query/geoquery my photos.
Tried this out today and it feels half-baked unfortunately. I can't get auth working (https://github.com/googleworkspace/cli/issues/198).
The decision to pass all params as a JSON string to --params makes it unfriendly for humans to experiment with, although Claude Code managed to one-shot the right command for me, so I guess this is fine. This is an intentional design per https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
I think we all have been working on our own bespoke CLI tools. MCPs are bloated, insecure token hogs. CLIs are easy to write and you can cut it down to only what you need, saving thousands of tokens per prompt. This is another one I'll add to my repertoire of claude CLIs to replace the MCP.
Claude Opus 4.6 couldn't figure out how to use it to write to a Google Sheet (something to do with escaping the !?) and fell back to calling the sheets API directly with gcloud auth.
> 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.
What is the practical difference between a "discovery service"+API and an MCP server? Surely humans and LLMs are better off using discovery service"+API in all cases? What would be the benefit of MCP?
Is this basically a CLI version of [1]? If so, I'm glad Google is being forward thinking about how developers actually want to use their apps.
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...
> gws doesn't ship a static list of commands.
Clever, but frustrating that they don’t bother to provide any docs on the actual commands this supports.
Basically Google’s take on GAM https://github.com/GAM-team/GAM
The fact that humans can use this feels like a side effect. The developer says it's "built for agents first" and "AI agents would be the primary consumers of every command, every flag, and every byte of output"[1].
[1] https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
I remember reading gog setup instructions, and thinking, "Create oauth app/client? That's bonkers." And as cool+useful as this project looks, it's quite a bit harder to get going, especially if you're not familiar with Google Console and OAuth (or not a dev).
Reading lots of comments about "MCP vs CLI" -- reminds me a bit of the "agent vs. script/app/rpa" debates. It's usually not one or the other, but rather, both.. or the right tool for the job (and that can shift over time).
Biggest complaint we have about MCP is bigger context windows and token spend. Tools do exist that address this. I have just one MCP endpoint with a half dozen tools behind it, including Gmail, Google Calendar, Docs, Github, Notion, and more. Uses tool search tool (ToolIQ) with tiny context footprint. Give it a whirl. https://venn.ai
"This is not an officially supported Google product."
Probably someone's hobby project or 20% time at best.
They need something like this as it's hard and flaky to automate Google apps with AI. However, step 2 drops me to a fairly technical looking page where I have to configure Google Cloud. If they had a one click installer to automate Google Apps it would be an absolute killer use case for AI for me.
Would be nice if the MCP implemented the Streamable HTTP MCP spec instead of the CLI one. I know this is already a HTTP API, but making it available as an MCP server that clients like Joey[1] can consume easily over network would be nice.
I think this blog post from the author is interesting: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
The move to CLIs has been really interesting lately. They're easy for agents to use. They're composable with other shell tools. It's going to be interesting to see if mcp sticks around or if everything just moves to service specific CLIs.
Interesting, but scary, given that this is not a google product. Who knows whether that breaks any TOS somehow.
Schema Discovery Service is interesting but I have been wondering whether it is finally time to start implementing HATEOAS[0] in REST services.
[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
How to expose my product suite's API to AI has been a roller coster ride. First it was tool calling hooks, then MCP, then later folks found out AI is better at coding so MCPs suddenly became code-mode, then people realized skills are better at context and eventually now Google has launched cli approach.
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)
this is just insane, now my lobster can stably do everything on my behalf vs. you do it all via computer use
very similar to gogcli(https://github.com/steipete/gogcli), but in RUST
I've been using `gog` but I'd rather have an agent-first thing. I don't want a big bad MCP that occupies all context all the time. I need my claw to be aware on how to edit things. As it so happens, right now `gog` works. But I'm eager to see how this develops.
Are integration vendors like Pipedream in trouble now that every company is pushing out MCP servers and CLIs to ride the AI craze? After the Twitter and Reddit API troubles of prior years, I can't imagine any company would willingly bring down the walls of their gardens and give easy access to precious user data. I'm waiting for the rug pull
This reminds me a bit of how the GitHub CLI evolved into a foundation for automation and tooling. Do you see the Google Workspace CLI primarily as something for humans using the terminal, or more as a stable interface that automation and AI agents can build on?
Totally thought this was built by Google. Great product!
Me: huh, 0.4.4 version, this project must have been around for a little while.
checks https://github.com/googleworkspace/cli/tags
v0.1.1 2 days ago
v0.2.2 yesterday
v0.3.3 18 hours ago
v0.4.2 9 hours ago
v0.5.0 8 minutes ago
Interesting times we live in..
Neat. I've been running something very similar to this locally for a few months now. They introduced all their documentation into markdown recently. I still rely on discover API and lenient cloud project permissions, so maybe some gains there. Will compare note later.
Building www.cliwatch.com, so you can keep an eye on how agent-friendly your CLI is ;) feel free to request a benchmark against your CLI docs. Cheers
Seems weird to require another tool (gcloud) to set it up, but it does look to be tightly integrated with google cloud.
Correct me if I'm wrong but the UX difficulty with the Google API ecosystem isn't resolved. It's the goddamn permissioning and service accounts. Great to have a CLI that every other minute says, "you can't do this" -- the CLI really needed to solve this to check my boxes.
Having the available commands change on you dynamically seems like an anti-pattern, but I suppose an AI can deal with it.
It's funny because all these cloud services are suddenly motivated to have truly useful CLIs.
Why cli instead of just HTTP API doc? The agent can use curl or write code to send requests.
Forget the Gemini extension - Gemini CLI sucks. Forget the MCP - MCP is beyond dead. But for codex or claude cli this is a game changer. Next question is how programmatic have they made the sheets interface... because Gemini sucks at sheets.
I can already see all the CTOs are getting excited to plug this in their OpenClaw instances.
Feel like this should be at the top of the README - not the bottom
> Disclaimer
> Caution
> This is not an officially supported Google product.
Great, i hope this becomes a trend now that agent skills want clis
GCP Next is Apr 22-24. Hope this continues to live afer that.
> This is not an officially supported Google product.
While I prefer Google's productivity apps to the Microsoft world in this case Google is just catching up to the APIs and tooling that Microsoft has provided for a long time: https://learn.microsoft.com/en-us/powershell/microsoftgraph/...
Google really know how to screw up a product experience.
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?
I have been working on extrasuite (https://github.com/think41/extrasuite). This is like terraform, but for google drive files.
It provides a git like pull/push workflow to edit sheets/docs/slides. `pull` converts the google file into a local folder with agent friendly files. For example, a google sheet becomes a folder with a .tsv, a formula.json and so on. The agent simply edits these files and `push`es the changes. Similarly, a google doc becomes an XML file that is pure content. The agent edits it and calls push - the tool figures out the right batchUpdate API calls to bring the document in sync.
None of the existing tools allow you to edit documents. Invoking batchUpdate directly is error prone and token inefficient. Extrasuite solves these issues.
In addition, Extrasuite also uses a unique service token that is 1:1 mapped to the user. This means that edits show up as "Alice's agent" in google drive version history. This is secure - agents can only access the specific files or folders you explicitly share with the agent.
This is still very much alpha - but we have been using this internally for our 100 member team. Google sheets, docs, forms and app scripts work great - all using the same pull/push metaphor. Google slides needs some work.