The MCP/AI angle here is real - there's been more API documentation written in the last 12 months than in the prior 5 years combined. What started as "make it work with AI agents" is quietly forcing companies to build things that humans can actually use programmatically too. Kind of a nice side effect of the agentic push.
Is this comment AI generated? I don't like to accuse people of generating comments, but looking at your comment history, almost all of them fit this pattern of a single paragraph with "LLM-isms", this one included (i.e. "the X angle here is real -").
I'm hoping Facebook will bring back API to access Groups. My family Photo is in it. I feeling trepidation because they failed to acquhire OpenClaw's author.
Totally. I was just remarking today how funny it is that it was apparently ok for humans to suffer from a dearth if documentation for years, but suddenly, once the machines need it, everyone is frantic to make their tools as usable and well-documented as possible
> everyone is frantic to make their tools as usable and well-documented as possible
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)
Google will slowly win at the AI game. They got everything going, lots of free usage and they are keeping it real, unlike openAI that rides a hype train
I mean, they are? GCP usage/revenue is growing faster than AWS and Azure. Mostly driven by Gemini pushing folks onto the platform and them deciding "why not move everything else too".
They're going to have to significantly up their game - IIUC, you can't use a Gemini subscription with OpenCode anymore, and the Gemini CLI is such utter trash that it's unusable (it doesn't even have a plan mode in the preview releases, and can barely maintain a connection to a server).
Really interesting. I was thinking about something similar regarding the shape of code. I have no qualms recommending my agents take static analysis to the extreme, though it would cumbersome for most people.
I found that strange as well. My guess is that `npm` is just the package manager people are most likely to already have installed and doing it this way makes it easy. They might think asking people to install Cargo is too much effort. Wonder if the pattern of using npm to install non-node tools will keep gaining traction.
For many, installing something with npm is still easier. It chooses the right binary for your OS/architecture, puts it on your PATH, and streamlines upgrades.
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.
To my knowledge NPM isn't shipped in _any_ major OSes. It's available to install on all, just like most package managers, but I'm not sure it's in the default distributions of macOS, Windows, or the major Linux distros?
system pip w/ sudo usually unleashes Zalgo, i’d rather curl | bash but npm is fine too. it’s just about meeting people where they’re at, and in the ai age many devs have npm
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.
> The install script checks the OS and Arch, and pulls the right Rust binary.
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.
> NPM has become the de facto standard for installing any software these days, because it is present on every OS.
That's not remotely true. If there is a standard (which I wouldn't say there is), it's either docker or curl|bash. Nobody is out there using npm to install packages except web devs, this is absolutely ridiculous on Google's part.
They're not doing so here, but shipping a wasm-compiled binary with npm that uses node's WASI API is a really easy way to ship a cross-platform CLI utility. Just needs ~20 lines of JS wrapping it to set up the args and file system.
There's no such thing as a truly "cross-platform" build. Depending on what you use, you might have to target specific combinations of OS and processor architecture. That's actually why WASM (though they went with WASI) is a better choice; especially for libraries, since anyone can drop it into their environment without worrying about compatibility.
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.
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.
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)
I've built a few internal tools using the Workspace APIs, and while they are powerful, the rate limits on the Drive API can be brutal if you are doing bulk operations. Does this repository handle automatic backoff and retries, or do we need to wrap it ourselves?
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
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.
They already have a HTTP API, but the real reason is that CLIs are emerging as the most ergonomic way for the current wave of AI agents to do stuff. There's a few benefits over APIs:
- 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.
CLI is probably more reliable. Also, the ergonomics for the person setting up the machine for the AI are better. They can check to see if the command is working without screwing with curl. It's also possible a human might want to use the software / service they're paying for.
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.
> 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
gcloud cli will probably also require you to make a Google Cloud project and stuff by clicking around their godforsaken webui. hopefully they streamlined that, it took me a long time to figure out when i wanted to write some JS in my spreadsheet
This is made by Google Devrel. It's not going to break the TOS, but it could be abandoned. That happens frequently with devrel projects, since they're not actually tasked with or graded on engineering projects.
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.
wow this will gel very well with my current project. Main hurdle i was facing was connecting with individual services via google oauth to get the data.
One of the very few good things from the AI race has been everyone finally publishing more data APIs out in the open, and making their tools usable via CLIs (or extensible APIs).
They aren't doing that though. At least not yet. It's generated from the discovery tool, which amounts to the spec of the existing API. If they want a high powered CLI they need to dig into the servers behind Google Workspace like they have when they've improved the web apps.
For all people have to say about Pete the openclaw guy he's been perhaps one of the most vocal voices about CLIs > MCPs (or maybe his is just the loudest?) and he also built a GSuite CLI that probably inspired this project.
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.
God, this is awful. 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?
Google Workspace API(s) keys and Roles was always confusing to me at so many levels .. and they just seem to keeping topping that confusion, no one is addressing the core (honestly not sure if that is even possible at this point)
Similar frustrations. I was only able auth using some Google app I created for an old project years ago that happened to have the right bits.
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.
I’ve been really unhappy with pretty much every Google product I’ve used except their consumer productivity tools — Gmail, Calendar, and Meet. Diving into Google Cloud has been extremely unsatisfactory
I ran a project for a company on Google Cloud a few years ago and enjoyed it once I got used to everything. I’d use it more now if they had better low end pricing to start projects there.
It’s a very different experience than AWS though and takes some getting used to.
i had to do all that the last time i wanted to do a little js in my google sheets. when i saw their quick start required gcloud already set up, i decided not to bother trying this out. idk why google makes something that should take 15s (clicking “ok” in an oauth popup) take tens of minutes to hours of head scratching.
The MCP/AI angle here is real - there's been more API documentation written in the last 12 months than in the prior 5 years combined. What started as "make it work with AI agents" is quietly forcing companies to build things that humans can actually use programmatically too. Kind of a nice side effect of the agentic push.
Is this comment AI generated? I don't like to accuse people of generating comments, but looking at your comment history, almost all of them fit this pattern of a single paragraph with "LLM-isms", this one included (i.e. "the X angle here is real -").
I find this form you're commenting on less annoying than people starting posts with "this." What a stupid way to say "I agree."
What gave you the impression that this was related to AI?
Was it the 100+ Agent Skills?
The Gemini CLI extension?
Or the bundled MCP server?
I'm hoping Facebook will bring back API to access Groups. My family Photo is in it. I feeling trepidation because they failed to acquhire OpenClaw's author.
This. I’ve been genuinely excited about MCP from the start mostly because you can use it by hand, too.
Totally. I was just remarking today how funny it is that it was apparently ok for humans to suffer from a dearth if documentation for years, but suddenly, once the machines need it, everyone is frantic to make their tools as usable and well-documented as possible
> everyone is frantic to make their tools as usable and well-documented as possible
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)
Well, mostly because you can now task an LLM with writing the docs.
You also have to expose the API in the first place.
Google will slowly win at the AI game. They got everything going, lots of free usage and they are keeping it real, unlike openAI that rides a hype train
yeah just like they’ve slowly won at cloud over AWS and Azure. oh wait
Remember that time they used their network effects to auto-enroll all Gmail users into their Facebook competitor and instantly won?
I mean, they are? GCP usage/revenue is growing faster than AWS and Azure. Mostly driven by Gemini pushing folks onto the platform and them deciding "why not move everything else too".
They're going to have to significantly up their game - IIUC, you can't use a Gemini subscription with OpenCode anymore, and the Gemini CLI is such utter trash that it's unusable (it doesn't even have a plan mode in the preview releases, and can barely maintain a connection to a server).
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...
Really interesting. I was thinking about something similar regarding the shape of code. I have no qualms recommending my agents take static analysis to the extreme, though it would cumbersome for most people.
I'm curious why `npm` is used to install a `rust` binary?
I found that strange as well. My guess is that `npm` is just the package manager people are most likely to already have installed and doing it this way makes it easy. They might think asking people to install Cargo is too much effort. Wonder if the pattern of using npm to install non-node tools will keep gaining traction.
Most people aren't going to have npm installed though. Nobody outside of web devs uses it.
Why not just downloadable binary then?
For many, installing something with npm is still easier. It chooses the right binary for your OS/architecture, puts it on your PATH, and streamlines upgrades.
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.
Hmm, that's right... thanks..
NPM as a cross platform package distribution system works really well.
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.
To my knowledge NPM isn't shipped in _any_ major OSes. It's available to install on all, just like most package managers, but I'm not sure it's in the default distributions of macOS, Windows, or the major Linux distros?
No package manager is. But of the ones that are installed by users, npm is probably the most popular.
What about pip? It's either installed or immediately available on many OSes
`pip install` either doesn’t work out of the box or has the chance to clobber system files though
system pip w/ sudo usually unleashes Zalgo, i’d rather curl | bash but npm is fine too. it’s just about meeting people where they’re at, and in the ai age many devs have npm
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.
This is about eight years old. The python situation has mostly gotten worse since https://xkcd.com/1987/
> The install script checks the OS and Arch, and pulls the right Rust binary.
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.
Yeah except you need to install NPM, whereas with a rust binary, which can easily compile cross platform, you don’t.
Honestly I’m shocked to see so many people supporting this
> NPM has become the de facto standard for installing any software these days, because it is present on every OS.
That's not remotely true. If there is a standard (which I wouldn't say there is), it's either docker or curl|bash. Nobody is out there using npm to install packages except web devs, this is absolutely ridiculous on Google's part.
Interesting fact, because cargo builds every tool it downloads from source, you can’t actually run cargo install on Google laptops internally.
They're not doing so here, but shipping a wasm-compiled binary with npm that uses node's WASI API is a really easy way to ship a cross-platform CLI utility. Just needs ~20 lines of JS wrapping it to set up the args and file system.
Doesn’t this seem excessive over just using rust’s cross platform builds?
There's no such thing as a truly "cross-platform" build. Depending on what you use, you might have to target specific combinations of OS and processor architecture. That's actually why WASM (though they went with WASI) is a better choice; especially for libraries, since anyone can drop it into their environment without worrying about compatibility.
Can you link to a sample of how I can do this?
Why should the package's original language matter?
When I use apt-get, I have no idea what languages the packages were written in.
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/...
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...
I think it is unrelated.
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.
"This is not an officially supported Google product."
Probably someone's hobby project or 20% time at best.
Basically Google’s take on GAM https://github.com/GAM-team/GAM
gog too, which my openclaw agent always stubbornly wants to use instead of delegating to a subagent + custom calendar/imap proxy server I built.
https://github.com/steipete/gogcli
This - gog - yes. But I think it is different than GAM which is an admin tool. reply
It's about time. Reminds me of how even Apple uses Jamf.
Except GAM is already heavily in training data and less likely to be called incorrectly.
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)
I've built a few internal tools using the Workspace APIs, and while they are powerful, the rate limits on the Drive API can be brutal if you are doing bulk operations. Does this repository handle automatic backoff and retries, or do we need to wrap it ourselves?
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
I can already see all the CTOs are getting excited to plug this in their OpenClaw instances.
Depends how it compares to gog.
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.
Why cli instead of just HTTP API doc? The agent can use curl or write code to send requests.
They already have a HTTP API, but the real reason is that CLIs are emerging as the most ergonomic way for the current wave of AI agents to do stuff. There's a few benefits over APIs:
- 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.
CLI is probably more reliable. Also, the ergonomics for the person setting up the machine for the AI are better. They can check to see if the command is working without screwing with curl. It's also possible a human might want to use the software / service they're paying for.
Why is it more reliable? The human usage point is fair, but I doubt how long it is still necesary.
if nothing else the cli gives very easy access to the HTTP api docs via `gws schema`
i’d rather not waste the context tokens re implementing their cli from scratch, if indeed it does a good job.
A CLI runs on the client, so they can embed client-side functionality like telemetry or caching.
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.
very similar to gogcli(https://github.com/steipete/gogcli), but in RUST
> quick setup
> 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
Having the available commands change on you dynamically seems like an anti-pattern, but I suppose an AI can deal with it.
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?
The readme is AI generated, so I am assuming the lack of effort and hand-off to the bots extends to the rest of this repository.
The contributors are a Google DRE, 5 bots / automating services, and a dev in Canada.
gcloud cli will probably also require you to make a Google Cloud project and stuff by clicking around their godforsaken webui. hopefully they streamlined that, it took me a long time to figure out when i wanted to write some JS in my spreadsheet
Interesting, but scary, given that this is not a google product. Who knows whether that breaks any TOS somehow.
This is made by Google Devrel. It's not going to break the TOS, but it could be abandoned. That happens frequently with devrel projects, since they're not actually tasked with or graded on engineering projects.
This appears to be published by Google itself
> Disclaimer
> This is not an officially supported Google product.
It’s published by Google, they just don’t provide active “support” for it.
Can you show that the major contributors are employed by Google? I'm not arguing, I'm genuinely asking. Thank you.
https://github.com/jpoehnelt
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.
Thank you!
You can check their GitHub profile. If they are in https://github.com/googlers, then they are internally verified.
https://github.com/googleworkspace -> in the about links is also verified as part of the Alphabet enterprise - https://github.com/enterprises/alphabet
Great, i hope this becomes a trend now that agent skills want clis
Seems weird to require another tool (gcloud) to set it up, but it does look to be tightly integrated with google cloud.
GCP Next is Apr 22-24. Hope this continues to live afer that.
Would be useful if it can atleast show google drive storage in folder structure
wow this will gel very well with my current project. Main hurdle i was facing was connecting with individual services via google oauth to get the data.
Haha in the world of AI/MCPs, all of a sudden we have a push for companies to properly build out APIs/CLI tools.
I have always said that if we had done for developers what we are doing for agents the whole world would have been a much better place.
Perhaps we will finally emerge from this decades-long dark age of bloated, do-everything GUI development tools being the fashionable happy path.
The AWS cli tool wants to have a talk… hard to find a more bloated mess of strung together scripts held together by tape.
One of the very few good things from the AI race has been everyone finally publishing more data APIs out in the open, and making their tools usable via CLIs (or extensible APIs).
I feel like the CLI craze started around 2020. That predates this chat GPT.
CharmCLI golang
Nushell rust
Warp. Shell
Were all around 2020 also that is when alt shells started getting popular probably for same reasons they still are.
But on the other hand a (possibly dark) pattern is emerging where companies are asking you to upgrade to a higher plan to access MCP.
I noted something similar a few weeks ago. Companies are finally putting APIs in front of things that should have had APIs for years!
About 90% of “make codebase better for LLMs” is just good old fashioned better engineering that is also good for humans.
yeah there's way more demand, and at the same time, it's way easier for the company to build and maintain (with the help of AI). Great to see!
Took them this long to realize MCPs are just worse APIs.
They aren't doing that though. At least not yet. It's generated from the discovery tool, which amounts to the spec of the existing API. If they want a high powered CLI they need to dig into the servers behind Google Workspace like they have when they've improved the web apps.
For all people have to say about Pete the openclaw guy he's been perhaps one of the most vocal voices about CLIs > MCPs (or maybe his is just the loudest?) and he also built a GSuite CLI that probably inspired this project.
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.
Hoping Apple will do the same with iCloud.
Don’t hold your breath
Lol
This is a very interesting way of building agent skills. Seems like the imperative way of orchestration/automation is making a comeback.
AI Agents are becoming first-class citizens for SaaS
God, this is awful. 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?
I find https://github.com/steipete/gogcli a bit easier (but still confusing to setup)
Google Workspace API(s) keys and Roles was always confusing to me at so many levels .. and they just seem to keeping topping that confusion, no one is addressing the core (honestly not sure if that is even possible at this point)
Similar frustrations. I was only able auth using some Google app I created for an old project years ago that happened to have the right bits.
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.
I’ve been really unhappy with pretty much every Google product I’ve used except their consumer productivity tools — Gmail, Calendar, and Meet. Diving into Google Cloud has been extremely unsatisfactory
I ran a project for a company on Google Cloud a few years ago and enjoyed it once I got used to everything. I’d use it more now if they had better low end pricing to start projects there.
It’s a very different experience than AWS though and takes some getting used to.
i had to do all that the last time i wanted to do a little js in my google sheets. when i saw their quick start required gcloud already set up, i decided not to bother trying this out. idk why google makes something that should take 15s (clicking “ok” in an oauth popup) take tens of minutes to hours of head scratching.